From apollo-request@umix.cc.umich.edu Sat Jul 1 00:59:24 1989 Message-Id: <8906301820.AA26834@xuucp.ch.apollo.com> From: pato@apollo.com Date: Fri, 30 Jun 89 14:23:10 EDT Subject: Re: su To: krowitz@richter.mit.edu Cc: apollo@umix.cc.umich.edu In-Reply-To: krowitz@richter (David Krowitz), fri, 30 jun 89 09:47:47 Oddly enough, I have both an Alliant FX/40 running BSD4.2 and and I can 'su' to root on both sets of machines *without* being a member of the 'wheel' group. There must be some other fairly wide-spread mechanism for setting up this access. All of our systems are standard distributions. We have not fooled with anything in the BSD packages that came with the machines. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) This behavior is part of BSD 4.3 not BSD 4.2 (therefore it exists in DOMAIN/OS sr10.x and not in DOMAIN/IX sr9.X) 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 Sat Jul 1 01:30:27 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8907010416.AA00089@icaen.uiowa.edu> Date: Fri, 30 Jun 89 23:04:23 CDT Subject: Re: help with "bind -inlib" under SR10.1 To: krowitz@richter.MIT.EDU Cc: apollo@umix.cc.umich.edu WRT posting <8906271412.AA03627@richter.mit.edu> from David Krowitz: > I'm trying to use the "-inlib" option to /com/bind under > SR10.1 with no success. I have a library of calcomp graphics > calls which is written in GMR. The library is compiled with > "ftn -pic" and then bound with the GMR library using > "bind -inlib /lib/gmrlib". My main program is compiled using > the defaults options. When I bind it using the following > shell script, I get no errors, and the program runs just fine: [ stuff deleted ] > To reduce the sizeof the main program, I'd like to bind it > to the calcomp graphics library using the "inlib" option > of bind. When I do this, I get the following errors: > > Undefined Globals: > > chrcod First referenced in letter.bin > justfy First referenced in letter.bin > plot First referenced in contour.bin > plots First referenced in contour.bin > symbol First referenced in letter.bin Look at chapter 4 of "Domain/OS Programming Environment Reference" ON: (011010-a00). In particular the paragraph near the bottom of page 4-5: "However, if you used bind to create the object module, then by default the global symbols in the library are NOT accessible to running programs. To make the global symbols accessible to running programs, you must use the -mark, -allmark, or -allkeepmark option when you bind." Also note the comments on the "-pic" compiler and the "-loadhigh" binder options. Dave Funk From apollo-request@umix.cc.umich.edu Sat Jul 1 05:32:24 1989 Date: 30 Jun 89 04:00:00 GMT From: conliffe%caen.engin.umich.edu%mailrus.uucp@rutgers.edu (Darryl C. Conliffe) Organization: U of M Engineering, Ann Arbor, Mich. Subject: Re: '' in pathnames Message-Id: <4425afed.b11a@falcon.engin.umich.edu> References: <8906300424.AA03855@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu This is not intended as a flame. It is intended as an offering of a view of Apollo (the workstation, not the company division). In article <8906300424.AA03855@umix.cc.umich.edu>, GBOPOLY1@NUSVM.BITNET (fclim) writes: > This may seem like correspondence between Darryl and myself. I've decided > to send this to this list because I support putting '' back. > > In article <441fd6ee.b11a@falcon.engin.umich.edu>, conliffe%caen.engin.umich > .edu%mailrus.uucp@csd4.milw.wisc.edu (Darryl C. Conliffe) writes > > > In article <8906290941.AA13520@umix.cc.umich.edu>, GBOPOLY1@NUSVM.BITNET > > (fclim) writes: > > > >From: conliffe%caen.engin.umich.edu%mailrus.uucp@csd4.milw.wisc.edu > > > > (Darryl C. Conliffe) [ Deleted 25 lines. Summary: I believe INS is a natural and fclim does not agree.] > > BTW, if you are just finding out about it, who taught you about the > > systems basics? They should have made that simple point evident. Sounds > > like a case of poor technology transfer. (I am *NOT* implying that it > > was your fault. Someone, maybe Apollo, dropped the ball.) > > Nobody introduced me to Apollo. I just walked in, applied for an account > and use Domain/IX straight off. What I know about Aegis, I picked up by > reading the manuals and thro comp.sys.apollo. I don't read manuals from > page 1 to the last page; but flip to the pages whenever I have to. > I end up transferred to the Computer Centre and made sys_admin. In this > capacity, I need to know about Aegis 'cos there are Aegis users besides > Domain/IX users. My condolences on being lowered (er, raised?) to sys_admin without benefit of training. I do not envy you. It might have helped to view the system as a unique implementation of a computer system with some similarities to other existing systems. Then you might have expected unique attributes, and maybe even grown fond of 'em. I left the comments in about M3 to recreate the context. We have a misunderstanding here. See NO NO NO below for explanation. > > > >Or, have you ever seen someone introduced to an Apollo by someone > > > >who knows only vi read a file? He vi's it. I love the look > > > >on that users face when I point to the file name on a pad and open > > > >it. > > > > > > How about someone who knows only Aegis and have never seen other Unix > > > boxes? He'll look everywhere for that @#$%&*))( EDIT key when he comes > > > upon a Sun. > > > > > And if he goes to an IBM-PC he'll have the same challenge to *LEARN* > > how to best use the machine. Computers and workstations are nice, > > but one still has to know *SOMETHING* to be able to make the > > most effective use of 'em. I've worked in situations where I > > was working on a PC, an Apollo, and a DG machine at various > > times during the same day. While sometimes confusing, their differences > > never were *INGHIBITIN*, just annoying at times. Oops! My ex editor tricked me! I thought I caught this error and fixed it (no G), but look at what ex got me! (Just kidding, I didn't see the first IN search pattern :=) > > > > Besides, you avoid the problem by staying on the Apollo which *DOES* > > have the EDIT key! :=) (In fact, I often moved files to the Apollo > > workstation to make use of DM. I have never moved anything for > > the priviledge of getting to vi!) > > I brought up the point about finding the EDIT key on a SUN because I find > your argument to be flawed. A guy just introduced to any new machine isn't > going to know the best way to use the machine right off. If he's keen, > he'll learn more about it and gradually master it. This points out why we differ. You seem to endorse acquiring system skills by experience as a desireable methodology. I believe training is very important. I believe that with a small investment in training, an Apollo user will be better at using an Apollo than new users of most other platforms. Without training, a user new to a system will do better on the system if it looks like the last system he was operating. That is my guess. The upshot is how a system should be evaluated, and what scenario (experience in other machines, or experience plus training) is reasonable. For the size of the investment, training seems advisable. > I have seen users (ie users new to Apollo but not to Unix) using more, cat > or vi to view a file instead of m3 (the mouse's right button). But after I > told them about m3, they started to use m3. They are *not* dumb; they just > don't know such a beast (m3) exists. (Darryl, that's how I interpreted your > view of such users -- they are dumb not to use m3). NO NO NO. You missed my point there. Ignorance is not stupidity. The point was that proper training is essential to full appreciate any system and to make the most productive use of that system. > What I wanted to say is that vi is not that user-unfriendly as it is hyped > to be. There are some shortcomings (like not knowing when it's in command or > input mode); but once you have the hang of it, it's not that difficult to use. > Its choice of characters for commands is more mnemonic than EDIT's choice. > Using for \search\; F6 for a delete-word command; etc isn't what > I consider to be mnemonic; I keep referring to HELP DM COMMANDS to figure > out the fastest way to delete a word. :=) I assume you mean you hit SHIFT-HELP and then type dm/keys of the command line to get an independent pad on the screen showing the key definitions. Each time I use vi, I swear I'm going to create a file holding the definitions of the commands so they will be available, too. > Of course, if I use the DM editor enuff times, these commands are going > get burned into my brain. This fact also applied to vi. If you have > perseverance to go beyond the first couple of lessons on vi, you'll going > to find that it's an ok editor to use. I grant you the learning curve > is steeper for vi, but it don't take an Einstein to learn and use vi. Agreed. I appreciate the presence of DM *AND* vi. You cannot get that anyplace else but in an Apollo. [ score card and comments deleted ] > I am sorry for giving you the impression that I am keeping tabs on scores. > Maybe I should have added one more line saying that all non-Apollo users > are winners. What I am trying to say is that we are flaming each other > instead of helping. Flamers are in a no-win situation. All this flamage > started on some bad decision by Apollo. I agreed with you and Scott -- they > should have left '\' untouched. I do not consider this exchange of views an exchange of flames. I believe you have valid points. Flames are usually just noise, complaints without merit nor insight. > Apollo should make the system flexible for everyone to customize their > environments to individual tastes. Remember the flames I send over about > DM "shut" and "ex" and the ability for sys_admins to break into a GPR_$borrow > mode? Furthermore, Domain/IX users (at least at SR9.7) are unable to use > stty to set the kill and werase characters (BSD only) and -echo on a Domain > input pad. These deficiencies are among what I consider INHIBITING. > Do we agree, therefore, that Apollo's advantages should be preserved while allowing an even greater amount of customization? I think so. I am not as sure that I agree with your desire for the machines to be something else other than what they are purported to be. However, I am sure we agree that all features offered should work they way they are documented! Right? From apollo-request@umix.cc.umich.edu Sat Jul 1 11:29:34 1989 Message-Id: <8907011447.AA05257@umix.cc.umich.edu> Date: Sat, 01 Jul 89 09:48:31 SST From: fclim Subject: Re: su To: APOLLO@UMIX.CC.UMICH.EDU "It is better to keep your mouth shut and let people think you're a fool than to open it and remove all doubts." I have done it this time; it's confirmed -- I'm a fool. Yesterday, I wrote > In article <8906291414.AA04731@lnic1.hprc.uh.edu> Andrew M. Wescott > writes > > >So what is wrong with having to belong to group "wheel" in > >order to su root? I miss the point entirely. Let the sysadm > >add whoever to wheel from edrgy, give them the password, and > >be done with it. > > Say what? We are talking about su, Andrew, ability to turn into > Superuser > in a single bound. We might as well give root's passwd to selected > people > and let them use login instead of su. What am I talking about? Of course, you have to give away the passwd to allow them to su to root. But, Andrew, *don't* put those selected few in the same group as "wheel" I have created 2 accounts for myself. Using edacct, I add fclim (per) staff (proj) cc (org) and fclim (per) sys_admin (proj) none (org) in that order. Normally, when I log in, it will be fclim.staff.cc which is an ordinary account. When I test out ideas (via shell scripts or otherwise), I will not accidently delete system files. After certifying these scripts to be bug free, I logs in as fclim.sys_admin to run the scripts as sysadmin Adding users to "wheel" group will give these users power to edit/delete files owned by root. If foo has the permission modes rwxr-xr-x root (owner) wheel (group) then these users will not be able to edit/delete foo. However, if we have for bar rwxrwxr-x root (owner) wheel (group) then bar may be accidently deleted. The users need not su to root to edit/delete bar. Have a happy 4th of July. fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. From apollo-request@umix.cc.umich.edu Sat Jul 1 11:35:38 1989 Message-Id: <8907011459.AA05369@umix.cc.umich.edu> Date: Sat, 01 Jul 89 11:09:43 SST From: fclim Subject: Re: PC to Apollo FTP To: APOLLO@UMIX.CC.UMICH.EDU > From: rab%ssc-vax%fluke.uucp@beaver.cs.washington.edu > (Robert A. Birgenheier) > Organization: Boeing Aerospace Corp., Seattle WA > Subject: PC to Apollo FTP > Message-Id: <2767@ssc-vax.UUCP> > > I talked recently with someone who was having problems trying to > connect from a pc to an Apollo via TCP/IP FTP. Here are the > particulars: > > Compaq 286 logged on to a Novell LAN > (Micom)-Interlan TCP/IP gateway on the server (NP600 card) > remote host is Apollo (DN160?, I think) > > He can sucessfully Telnet to the Apollo, can FTP to Administrator's > account on Apollo, but when trying to FTP to a user's account is told > can't set to home directory' or something like that. Anyone out there > with any help/suggestions? I'm going to open my mouth again and let all know I am a fool. I think (ie I'm *not* sure) the problem lie with the process-uid of the /etc/rc process. Ftpd is the deamon (server) that handles incoming ftp calls. If the login is successful, it will setuid(3) to the user-id you specified with the FTP user command. It will also setgid(3) to the group and chdir(2) to the home directory of that user. The group and home directory info is obtained from /etc/passwd. But, ftpd can only setuid(), setgud() and chdir() only if ftpd was run by root. ftpd is run on a demand-basis by inetd which is started by /etc/rc. If /etc/rc is run by root, then inetd and ftpd will inherit the root process-uid. (run "ps lag" and look under the UID column). /etc/rc is run by /etc/run_rc which is spoofed off by `node_data/startup.xxx. The process-uid of /etc/run_rc is %.server. To make /etc/rc have root process-uid, do % chown root /etc/rc % chmod 4755 /etc/rc I hope this works. fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. From apollo-request@umix.cc.umich.edu Sat Jul 1 13:25:01 1989 Message-Id: <8907011500.AA05375@umix.cc.umich.edu> Date: Sat, 01 Jul 89 11:16:35 SST From: fclim Subject: UNIX and things To: APOLLO@UMIX.CC.UMICH.EDU > From: FERGUSON%TMASL.EXXON.COM@CUNYVM.CUNY.EDU > Subject: UNIX and things > > If you bomb out a process, can Unix give you a traceback of what > happened? I'm going to open my mouth again and let all know I am a fool. I think (ie I'm *not* sure) that if Apollo allows the image of the process to be dumped (known as a core dump in the Unix community) whenever the process bombs out, then we could use dbx, adb, sdb, etc to debug the core. There should be a traceback somewhere in the core. fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. From apollo-request@umix.cc.umich.edu Sat Jul 1 17:23:45 1989 Date: Sat, 1 Jul 89 13:01:12 CDT From: wescott@lnic1.hprc.uh.edu Message-Id: <8907011801.AA09885@lnic1.hprc.uh.edu> To: APOLLO@umix.cc.umich.edu, GBOPOLY1%NUSVM.BITNET@cunyvm.cuny.edu Subject: Re: su Well basically I'm a tyrant, as I don't let anyone have SU privilege. That's one solution! Andrew Wescott From apollo-request@umix.cc.umich.edu Sat Jul 1 17:26:57 1989 Date: Sat, 1 Jul 89 13:12:47 CDT From: wescott@lnic1.hprc.uh.edu Message-Id: <8907011812.AA09894@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu Subject: Final Comments on Su Okay let's summarize this argument. 1.) Apollo has defended themselves properly on having membership in group wheel in order to su root. This is indeed BSD4.3 behavior that I have verified. The one thing I don't like is the inability to have real UNIX su privilege while logged onto an Apollo console. But this is not a flag burning issue! There are ways around this with some creativity. 2.) fclim has pointed out the usefulness of having different accounts for different activities. You can let some users have minor privileges via acls that will limit your everyday administrative headaches. All I originally wanted to clarify was the group wheel/su argument relative to BSD4.3. We have obviously uncovered some good alternatives relative to Apollo's O/S that you cant't do on some other systems. But I thinked we've worked this one over enough. I'm tired of reading mail with Subject: Su .... Let's move on. Andrew Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Sun Jul 2 04:04:24 1989 Date: 28 Jun 89 20:20:00 GMT From: lray%uxh.cso.uiuc.edu%ux1.cso.uiuc.edu.uucp@uxc.cso.uiuc.edu Subject: hang at boot Message-Id: <18300010@uxh.cso.uiuc.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu First off, forgive typos in this note. The vt100 emulator that I'm using for vi does not work. Long login after boot seems to be caused by a problem with initializing some sort of cache. The system routine that hangs is (if I recall correctly) name_$find_uid_lc. Here is an easy way to demonstrate it: boot your system on a ring that contains uncatalogued diskless nodes. Immediately after logging in, do an lcnode. The node will appear to hang. It won't really hang, of course. After a while, the lcnode will complete, and then future lcnodes will work fine. Or, if you wd/cd to something in the // directory immediately after boot, you should see the same sort of hang. Leland Ray UIUC Civil Engineering (217) 333-3821 From apollo-request@umix.cc.umich.edu Sun Jul 2 05:25:22 1989 Date: 30 Jun 89 14:04:17 GMT From: bgo%pbhya%pacbell%amdahl%nsc%voder.uucp@ucbvax.Berkeley.EDU (Bud Odekirk) Organization: Pacific * Bell, San Ramon, CA Subject: Source for a simple editor Message-Id: <28136@pbhya.PacBell.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We are in the process of converting 500 people from DPSS mail to Unix mail (mailx). We need a very simple editor that would take little or no training to use. The only feature that we really need is the ability to make corrections on the previous line after you have pressed the return key. Most of our users are accessing the system with IBM PC's or compatible. I would really appreciate any help. 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 Mon Jul 3 07:28:40 1989 Message-Id: <8907031023.AA00439@umix.cc.umich.edu> Date: Mon, 03 Jul 89 17:58:40 SST From: fclim Subject: Re: '' in pathnames To: APOLLO@UMIX.CC.UMICH.EDU Hi, I just found out that "wd ~com" doesn't work no more on SR10. It's now "wd ~/com". *I* believe: Backslash was eliminated as a metachar 'cos Unix (Bourne, C and Korn shells) uses the backslash in the same way /com/sh uses the (@) sign. Now /com/sh users need a '/' between ~ and the next component because C and Korn shell resolve ~foo to the home directory of foo. Furthermore SR10 is case-sensitive because Unix has been case-sensitive all along. I am beginning to wonder if Apollo Inc is removing the Aegis shell bit by bit. Can someone from Apollo.com gives us more details on the long term direction of HP/Apollo? fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. From apollo-request@umix.cc.umich.edu Mon Jul 3 13:28:39 1989 Date: 3 Jul 89 15:17:00 GMT From: pcc%apollo.uucp@EDDIE.MIT.EDU (Peter Craine) Organization: Apollo Computer, Chelmsford, MA Subject: Re: Long login time for root Message-Id: <443359c0.20291@apollo.COM> References: <12151@polyslo.CalPoly.EDU>, <366@quintro.UUCP>, Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article abair@turbinia.oakhill.uucp (Alan Bair) writes: >We have a DN10K that has the same problem of slow logins the >first time after a boot. It happened with 10.0 and after an >upgrade to 10.1 it still does it. > >I asked our local rep and he hadn't noticed it on any of their >machines. He suggested I call the service line, which i have not >done yet. > >Alan Bair >UUCP cs.utexas.edu!oakhill!turbinia!abair Yes, we know that there is a "problem" here. When you first try to log into an SR10 node, the first thing that the node needs to do is to use NCS to find a registry server (rgyd). The DM (which is, most likely swapped out right then) will request registry information (through shared libraries that are also, quite likely, swapped out). Where does the DM look to get this registry information? Well, it probes the network to find a RGYD. As it turns out, this is the longest part of logging in (all other things being equal). Every time that someone logs in after that, the DM will already know where to go to find a RGYD and will use that one from then on (once again, all other things being equal). Unfortunately, the DM doesn't store the RGYD location anyplace, so that info is lost when the system shuts down. The good folks in R&D are looking into ways to have this information saved across boots. I don't know what the plan is to implement this, so I won't say much more. Not all of us here think that you're crazy. All SR10 nodes will experience this. Others have mentioned that you have to wait "a couple of minutes after the system boots" to see the RGYD on your own node. I suspect that this has to do with RGYD startup time, but I'm not certain. I have experienced this before, but I've not had the time to look into it. Peter Craine, NACS From apollo-request@umix.cc.umich.edu Mon Jul 3 13:37:33 1989 Date: 3 Jul 89 15:30:00 GMT From: pcc%apollo.uucp@eddie.mit.edu (Peter Craine) Organization: Apollo Computer, Chelmsford, MA Subject: Re: su Message-Id: <443365b7.20291@apollo.COM> References: <366@quintro.UUCP>, <552@parcplace.pplace.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <552@parcplace.pplace.COM> khaw@pplace.COM (Mike Khaw) writes: > > I have to do "stty -tabs" to get ls listings to line > up right, but I don't have to do that for non-root > logins. Users probably have "ts 9 -r" in their startup_dm.. Put one in root's startup_dm and this will probably go away. > > Hitting the HELP key only gets you generic Domain_OS > help, but not man files. Non-root accounts get both > Domain_OS help and man files with the HELP key. Sounds like key definitions. Check out one non-root account's key definitions and do appropriate 'kd's for root. > >(Not-necessarily-root) Domain_OS vi weirdities (no flames >about using vi, please -- I have to work on many different Unix >machines and it's not worth the aggravation to me to learn the DM >editor): > > Occasionally, if you open a shell window and start up > vi immediately, vi prints some complaint about not > knowing what an apollo_ terminal type is, goes > into line mode and then some state where it's hung. > If I kill the vi process and then again try vi in the > same window, it works fine. Sounds like it's time for the generic vi problem-fixer. 1) log on as root 2) rm -rf /dev/ttyp* /dev/pty* 3) /etc/mkdev /dev pty 4) reboot the node. This clears up the majority of vi problems. For anything else, I'd call the 800 number. > > (Must be a keymap problem ...) ^^ (control-caret) doesn't > do anything (it's supposed to take you to the previous file > you were editing). I also wish the bsd environment did > proper keymaps for ^u (kill line) and ^w (kill word). Use your own keydefs. Try (in the command window) kd ^u cms;tl;xd line_del ke This will delete the line that your cursor is on. [this is the current keydef for the key. >Mike Khaw Peter Craine, NACS I know I put my .signature with the appropriate disclaimer in here somewhere! From apollo-request@umix.cc.umich.edu Mon Jul 3 21:35:09 1989 Date: 3 Jul 89 19:30:00 GMT From: nazgul%apollo.uucp@eddie.mit.edu (Kee Hinckley) Organization: Apollo Computer, Chelmsford, MA Subject: Re: vt100 -- alternatives? Message-Id: <44343c35.1b147@apollo.COM> References: <8254@batcomputer.tn.cornell.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8254@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu (Moshe Braner) writes: >[] > >I am having problems with the vt100 emulator supplied by Apollo. >It came without sources (why?!) so I cannot fix it. Is there an Did you get sources for anything else? >alternative program, PD perhaps? All I really need is a way to >control the TEXT in a window: cursor addressing, erase to EOL, >erase to EOS -- via escape sequences of chars output to the window. What kind of problems are you having? Have you reported them? >(I would also need a way to invoke the alternative instead of the >Apollo vt100 automatically when a program (e.g., vi) uses TERMCAP.) You *might* be able to do that by replacing the vt100 program with it, I have no idea whether it would work though. >The Apollo "vt100" thingy insists on changing the font to its own One would expect the vt100 emulator to switch to a vt100 font :-). In any case, look in /sys/dm/fonts and you can replace the vt100 fonts with ones of your own choosing. >choosing, and hangs mysteriously at times during a "vt100 rlogin". Can you post (and/or submit an APR) with more details? -kee -- ### User Environment, Apollo Computer Inc. ### Public Access ProLine BBS ### ### {mit-eddie,yale}!apollo!nazgul ### nazgul@pro-angmar.cts.com ### ### nazgul@apollo.com ### (617) 641-3722 300/1200/2400 ### I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. From apollo-request@umix.cc.umich.edu Mon Jul 3 21:35:20 1989 Date: 3 Jul 89 19:34:00 GMT From: nazgul%apollo.uucp@EDDIE.MIT.EDU (Kee Hinckley) Organization: Apollo Computer, Chelmsford, MA Subject: Re: Opening a stream to nil files Message-Id: <44343f7f.1b147@apollo.COM> References: <8906211239.AA02260@umix.cc.umich.edu>, <693@idacom.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <693@idacom.UUCP> danny@idacom.UUCP (Danny Wilson) writes: >I got this format from a _very_ old Apollo technical bulletin. However, >recently I heard that SR10 uses a new format... Is this true? Yes. >Will my program still work? Any comments out there? I don't believe that it will. However the new format is now documented (well, has a header file) in /usr/include/apollo/fontn.h. -kee -- ### User Environment, Apollo Computer Inc. ### Public Access ProLine BBS ### ### {mit-eddie,yale}!apollo!nazgul ### nazgul@pro-angmar.cts.com ### ### nazgul@apollo.com ### (617) 641-3722 300/1200/2400 ### I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. From apollo-request@umix.cc.umich.edu Mon Jul 3 21:35:23 1989 Date: 3 Jul 89 19:43:00 GMT From: nazgul%apollo.uucp@eddie.mit.edu (Kee Hinckley) Organization: Apollo Computer, Chelmsford, MA Subject: Re: go to old directory == 'back' ?? Message-Id: <443447ef.1b147@apollo.COM> References: <678@idacom.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <678@idacom.UUCP> danny@idacom.UUCP (Danny Wilson) writes: >I thought this would be a great function for the Aegis shell. I made >the following shell scripts: > >file: wd > eon > if eqs ^1 "" then > /com/wd # no parameters, just print where we are > return > endif > old := ^"/com/wd" > export old > /com/wd ^1 > >file: back > eon > back := ^old > old := ^"/com/wd" > /com/wd ^back > dlvar back > /com/wd > >However, because the variable 'old' gets set at a lower shell level it >is undefined within program 'back'. Has anyone got a solution for >a (seemingly) easy problem like this? First of all you should probably stop using /com/wd, and just use wd. wd is a builtin at SR10 (one program per process and all that). The version in /com is a shell script, so it will still work, it's just slower. Now for the problem. There is no way to have a shell script change a variable above it unless you "source" the shell script. To do what you want I think the best solution would be: wd: #!/com/sh eon if eqs ^1 "" then wd else wd > ^HOME/.olddir wd ^1 endif back: #!/com/sh eon read back < ^HOME/.olddir wd > ^HOME/.olddir wd ^back Note that I haven't tested this! -kee -- ### User Environment, Apollo Computer Inc. ### Public Access ProLine BBS ### ### {mit-eddie,yale}!apollo!nazgul ### nazgul@pro-angmar.cts.com ### ### nazgul@apollo.com ### (617) 641-3722 300/1200/2400 ### I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. From apollo-request@umix.cc.umich.edu Mon Jul 3 21:38:19 1989 Date: 3 Jul 89 19:48:00 GMT From: nazgul%apollo.uucp@eddie.mit.edu (Kee Hinckley) Organization: Apollo Computer, Chelmsford, MA Subject: Re: Logging into Apollo via modem Message-Id: <44344c99.1b147@apollo.COM> References: <8906272352.AA05126@richter.mit.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8906272352.AA05126@richter.mit.edu> krowitz@RICHTER.MIT.EDU (David Krowitz) writes: >Here is a command file we use to set up the SIO line characteristics If you are using SR10.1 or greater I highly recommend using the standard Unix mechanisms. They give you greater security (ability to limit the users of the system and require a dialin password), greater reliability (less hanging, less likely to leave processes around) and they reset the terminal characteristics so the person before you can't die in raw mode and leave you lost. -kee -- ### User Environment, Apollo Computer Inc. ### Public Access ProLine BBS ### ### {mit-eddie,yale}!apollo!nazgul ### nazgul@pro-angmar.cts.com ### ### nazgul@apollo.com ### (617) 641-3722 300/1200/2400 ### I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. From apollo-request@umix.cc.umich.edu Tue Jul 4 07:23:40 1989 Date: 4 Jul 89 09:07:38 GMT From: larss%draken%kth%mcvax.uucp@uunet.uu.net (Lars Schylberg) Organization: Royal Institute Of Technology, Stockholm, Sweden Subject: makefile problem under 10.1 Message-Id: <1239@draken.nada.kth.se> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have found a problem with our old makefile that worked under 9.7 but is not working now after we have changed to 10.1. The following is our test makefile: >-------------------------------------------------------------- MAKEALL = set * ; for d do echo $$d && test -f $$d; done; exit 0 all: $(MAKEALL) ------------------------------------------------------------------< We have found that this file can be run under the 9.7 version of make, but fails under the 10.1 version. The problem is that test command can not be combined together with the for command. Could anyone give us a hint who to come around this problem. Lars Schylberg and Huang Zhexue. From apollo-request@umix.cc.umich.edu Tue Jul 4 07:25:46 1989 Date: 4 Jul 89 09:10:30 GMT From: larss%draken%kth%mcvax.uucp@uunet.uu.net (Lars Schylberg) Organization: Royal Institute Of Technology, Stockholm, Sweden Subject: makefile problems under 10.1 Message-Id: <1240@draken.nada.kth.se> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Sorry for posting this again but it seems like my signature was lost. --- We have found a problem with our old makefile that worked under 9.7 but is not working now after we have changed to 10.1. The following is our test makefile: >-------------------------------------------------------------- MAKEALL = set * ; for d do echo $$d && test -f $$d; done; exit 0 all: $(MAKEALL) ------------------------------------------------------------------< We have found that this file can be run under the 9.7 version of make, but fails under the 10.1 version. The problem is that test command can not be combined together with the for command. Could anyone give us a hint who to come around this problem. Lars Schylberg and Huang Zhexue. Lars Schylberg Email: larss@fmi.kth.se (Internet) Department of Photogrammetry larss@sekth.bitnet (Bitnet) Royal Institute of Technolgy Tel. +46 8 790 86 33 (office) S-100 44 STOCKHOLM, SWEDEN Fax. +46 8 10 91 99 From apollo-request@umix.cc.umich.edu Wed Jul 5 07:25:49 1989 Date: 5 Jul 89 00:44:50 GMT From: heap%bmc1%draken%kth%mcvax.uucp@uunet.uu.net Organization: Biomedical Center, University of Uppsala, Sweden Subject: Problems with setting the colour map in GPR Message-Id: <1615@bmc.uu.se> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi, I am currently working on a GIFviewer for my apollo dn4000. I don't know whether I am reinventing the wheel, and such a program already exists, but still I am... Anyway: I have come so far that the picture is displayed alright, but for the colours! As you can see from the code fragment I have enclosed, I call gpr_$set_color_map in what I belive the correct way. The problem is that the image still is displayed in the default colour map, and not in mine. I verified this by commenting the gpr_$set_color_map call out. I get no errors from gpr_$set_color_map, just wrong colour map. The call chain is something like this: main -> init (initializes gpr) -> readscreen (loads global data) -> readimage -> initcolors -> color_entry -> gpr_$terminate Could somebody please tell me what I am doing wrong! -- Karl-K|nig K|nigsson (if you reply by mail, use the address below rather than the one in the header - that one might cause the letter to go astray) +----------------------------------------------------------------------+ | Email: Koenig@tdb.uu.se or Syskoenig@kemist.uu.se (se=sweden) | | Tel : +46 - (0)18 - 13 55 66 (home) or 18 29 78 (work) | +----------------------------------------------------------------------+ |"Why stop now, just when I'm hating it" -- Marvin the Paranoid Android| +----------------------------------------------------------------------+ void init(mode) gpr_$display_mode_t mode; { . . as in the c-examples in the gpr manual . } gpr_$color_t color_entry(red, green, blue) short red, green, blue; { return (red << 16) + (green << 8) + blue; } void initcolors(colormap, ncolors) unsigned char colormap[256][3]; int ncolors; { register i; static gpr_$pixel_value_t start_index = 0; gpr_$color_vector_t gpr_color_map; for (i=0; i < ncolors; i++) gpr_color_map[i] = color_entry(colormap[i][0], colormap[i][1], colormap[i][2]); gpr_$set_color_map(start_index, ncolors, gpr_color_map, status); check("setting color map"); } void main(argc,argv) int argc; char *argv[]; { . . init(gpr_$borrow); /* initialize the GPR graphics package */ . . readscreen(); /* load global screen data */ . . readimage(); /* read and uncompress the current image */ . . gpr_$terminate(false, status); } --------------------------------------------------------------------------- From apollo-request@umix.cc.umich.edu Wed Jul 5 09:34:30 1989 Message-Id: <8907051303.AA02804@umix.cc.umich.edu> Date: Wed, 05 Jul 89 18:45:53 SST From: fclim Subject: Switching files in vi (was [Re: su] as a flavor to Andrew Wescott) To: One ADU to another In article <552@parcplace.pplace.COM> khaw@pplace.COM (Mike Khaw) writes: > >(Not-necessarily-root) Domain_OS vi weirdities (no flames >about using vi, please -- I have to work on many different Unix >machines and it's not worth the aggravation to me to learn the DM >editor): > > (Must be a keymap problem ...) ^^ (control-caret) doesn't > do anything (it's supposed to take you to the previous file > you were editing). I also wish the bsd environment did > proper keymaps for ^u (kill line) and ^w (kill word). It isn't ^^ (control-caret) as documented in the manual, but is ^~ (control-tilde). I don't think it's a keymap problem 'cos vi pulls the pad into a vt100 which ignore the DM key definitions. fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. From apollo-request@umix.cc.umich.edu Wed Jul 5 11:36:55 1989 Message-Id: <8907051320.AA03260@umix.cc.umich.edu> Date: Wed, 5 Jul 89 09:15 EDT From: FERGUSON%TMASL.EXXON.COM@CUNYVM.CUNY.EDU Subject: RE: GPR Colour Maps To: apollo@umix.cc.umich.edu X-Vms-To: APOLLO My experience with GPR and color maps is as follows: I know that changing a color map requires that the display is acquired. Otherwise, you'll get a status error back. The arguments for gpr_$set_color_map(start,num_entries,map,status); are kind of funny. The 'start' is a long (or 4-byte) integer, the 'num_entries' is a short (16-bit) integer, the 'map' is an array of long integers, and status is finally a status_$t, or 4-bytes. These calls were all built back when the 68010 had only a 16-bit data bus, so two-byte integers were used whenever possible to save time (this is my theory, not gospel). Since then, for compatibility, the two-byte/four-byte conflict has continued. With FORTRAN code, it creates a problem in keeping code standard, because fortran doesn't know about integer*2 or *4. Anyway, those have been my common problems with gpr_$set_color_map. The only other thing I can think of is not including the insert file, but that would give access violations in everything you try. Scott Ferguson ferguson@erevax.bitnetr minus the 'r' -- VMS doesn't have a .signature ;-( From apollo-request@umix.cc.umich.edu Wed Jul 5 11:42:48 1989 Date: 4 Jul 89 12:36:31 GMT From: horst%pcsbst%unido%mcvax.uucp@uunet.uu.net (horst) Organization: PCS GmbH, Pfaelzer-Wald-Str. 36, 8000 Muenchen; West-Germany Subject: Re: Implementation of Ada Tasks under Unix Message-Id: <871@pcsbst.UUCP> References: <88@runxtsa.runx.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <88@runxtsa.runx.oz> jon@runx.oz (Jonathon Seymour) writes: >How are Ada tasks implemented in the Apollo (Verdix) version running >under 4.3bsd Unix? > >Specifically, is an Ada program ever blocked by the operating system >even if one of its tasks is able to run? Yes it does, at least in the Unix Sys V Version. Try this one: with text_io; use text_io; procedure hk is task t; task body t is s : string (1..80); i : integer; begin put_line ("t"); get_line (s,i); put_line (s (1..i)); end; begin put_line ("hk"); end; I don't understand why it blocks. This one doesn't: with text_io; use text_io; procedure hk is task t; task body t is s : string (1..80); i : integer; begin put_line ("t"); get_line (s,i); put_line (s (1..i)); end; task tt; task body tt is begin put_line ("tt"); end; begin put_line ("hk"); end; (Perhaps it's not an error but a feature.) Regards, Horst ========== Horst Kern PCS Computer Systeme GmbH Tel. : 089/68004-279 Pfaelzer-Wald-Str. 36 UUCP : ...uunet!unido!pcsbst!horst D 8000 Muenchen 90 >From US : ...pyramid!pcsbst!hk ------------------------------------------------------------------------ From apollo-request@umix.cc.umich.edu Wed Jul 5 11:46:53 1989 Message-Id: <8907051302.AA02800@umix.cc.umich.edu> Date: Wed, 05 Jul 89 18:36:07 SST From: fclim Subject: Re: vt100 -- alternatives? To: APOLLO@UMIX.CC.UMICH.EDU In article <44343c35.1b147@apollo.COM>, nazgul%apollo.uucp@eddie.mit. edu (Kee Hinckley) > In article <8254@batcomputer.tn.cornell.edu> braner@tcgould.tn. > cornell.edu (Moshe Braner) writes: > > The Apollo "vt100" thingy insists on changing the font to its own > > One would expect the vt100 emulator to switch to a vt100 font :-). > In any case, look in /sys/dm/fonts and you can replace the vt100 > fonts with ones of your own choosing. I don't think anyone can just simply cpf /sys/dm/fonts/vt100xxx -r (I don't know which font vt100 uses; so I put in the xxx). The reason is that there are some vt100-ism in the fonts. The important ones are those fonts for the control chars (ASCII 1 to hex 1f). These chars may be missing from . Use edfont to grab those control chars from the vt100 fonts and the rest from your favorite font. fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. From apollo-request@umix.cc.umich.edu Wed Jul 5 15:32:18 1989 Date: 5 Jul 89 15:00:50 GMT From: i91%nikhefh%mcvax.uucp@uunet.uu.net (Fons Rademakers) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: problem with PAD_$DEF_PFK under SR10 Message-Id: <217@nikhefh.hep.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I want to redefine in a program the third mouse button. I managed to do this and it works nicely under SR9.7. However, under SR10 it does not work anymore like under SR9.7. The test program is doing the following (see source at end of message): it redefines the M3 key to open the file pointed at in the vi editor (as opposed to using the DM editor). After running the program point at a file name in the transcript pad of the process it was run in and click the third mouse button. The string 'vi filename' will be submitted into the input pad of the process (under SR9.7). However, under SR10 the key is not redefined when clicking in the transcript pad of the process. It is only redefined for the input pad (type a filename in the input pad and click the third mouse button). The question is what is the problem under SR10, I would expect the input pad not to be STREAM_$STDOUT. What is the stream id for the transcript pad? How can I get it to work under SR10? Thanks in advance, Fons Rademakers PS: if this message came to you via BITNET the DMCMND string might be scrambled thanks to IBM. ================ test program ========= PROGRAM TT * %INCLUDE '/sys/ins/base.ins.ftn' * INTEGER IST CHARACTER*4 KEY CHARACTER*128 DMCMND * KEY = 'M3 ' * DMCMND='/[~a-zA-Z@@@;._@@@-$0-9@@@/@@@\~`]/dr;\[~a-zA-Z@@@;._@' + //'@@-$0-9@@@/@@@\~`]\;/?/xc cm;ti;tl;xd junk;es ''vi @'''';' + //'xp cm;tr;es ''@'''';en' * CALL PAD_$DEF_PFK(STREAM_$STDOUT, KEY, DMCMND, INT2(127), IST) PRINT *, 'STATUS =', IST * END -- Org: NIKHEF-H, National Institute for Nuclear and High-Energy Physics. Mail: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: (20)5925018 or 5925003 Telex: 10262 (hef nl) UUCP: i91@nikhefh.hep.nl BITNET: nikhefh!i91@mcvax.bitnet From apollo-request@umix.cc.umich.edu Wed Jul 5 19:31:15 1989 Date: 5 Jul 89 20:54:22 GMT From: jchiang%orion.cf.uci.edu%usc%cs.utexas.edu%vmsa.cf.uci.edu@tut.cis.ohio-state.edu Organization: University of California, Irvine Subject: change process name Message-Id: <2192@orion.cf.uci.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi there, Does someone know how to change the process name when this process is running at a remote node? Thank you. Jeff Chiang@vmsa.cf.uci.edu From apollo-request@umix.cc.umich.edu Wed Jul 5 19:37:49 1989 Date: 5 Jul 89 20:28:24 GMT From: khaw%pplace.uucp@uunet.uu.net (Mike Khaw) Organization: ParcPlace Systems, Mt. View CA Subject: root vs. non-root differences (was Re: su) Message-Id: <563@parcplace.pplace.COM> References: <366@quintro.UUCP>, <552@parcplace.pplace.COM>, <443365b7.20291@apollo.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Thanks to Peter Craine for pointing out how to make root have the same keymappings and tty behavior as non-root accounts. It turns out that (on my machine) although root and ordinary accounts all have their environment set to bsd and shell set to csh, root gets its key definitions from /sys/dm/std_keys.basic, while the others get their key definitions from /sys/dm/std_keys.unix. That's why I was perplexed about the differences. I still wonder why root only gets the key defs from std_keys.basic, though. Mike Khaw -- ParcPlace Systems, 1550 Plymouth St., Mountain View, CA 94043 415/691-6749 Domain=khaw@parcplace.com, UUCP={uunet,sun,decwrl}!parcplace!khaw From apollo-request@umix.cc.umich.edu Thu Jul 6 01:24:21 1989 Date: 6 Jul 89 02:05:52 GMT From: weiner%novavax%twwells.uucp@uunet.uu.net (Bob Weiner) Organization: Nova University, Fort Lauderdale, FL Subject: Re: '' in pathnames Message-Id: <1366@novavax.UUCP> References: <8907031023.AA00439@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu > I am beginning to wonder if Apollo Inc is removing the Aegis shell > bit by bit. Can someone from Apollo.com gives us more details on the long > term direction of HP/Apollo? I'm sure someone at Apollo will answer but you don't really need an official answer to this question to clearly understand HP/Apollo's direction, at least at a high level. Many technical details have not been announced. HP's non-Apollo workstations will not run Aegis (maybe in the lab for fun, but not for the public). Apollo and HP want their machines to run the same operating system. Neither party really wants to be burdened with marketing a totally new operating system at this point. All that leaves is UNIX. In the HP/Apollo case, high level officials at both companies have voiced strong support for the OSF direction. OSF/1 and OSF/2 in all likelihood will be their major integration OS platform. Apollo is already known to be doing much work in Motif-based interfaces. HP is certainly not standing still either. UNIX. You can love it or hate it but every vendor can spell it and port it. And its better than IBM's SAA OSs (too numerous to count). So it's going to be here a long time. Apollo will support Aegis for a long time (possibly five years since they can't even get many of their own people off it) but they definitely are pushing customers and development efforts towards portable, UNIX based software. -- Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner (407) 738-2087 From apollo-request@umix.cc.umich.edu Thu Jul 6 09:30:18 1989 Date: 5 Jul 89 21:10:12 GMT From: danny%idacom%alberta%ncc%pyramid%amdahl.uucp@ames.arc.nasa.gov (Danny Wilson) Organization: IDACOM Electronics Ltd., Edmonton, Alta. Subject: SR10 Installation Message-Id: <701@idacom.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Our [new] sys_admin has been saying that it is impossible to install SR10 (with Mentor SW) We have: a bunch of DN3000's with NO tapes, a DSP90 with attached 300 Meg drive Danford cartridge tape 9 track tape Is it true that we cannot load SR10 with this configuration? Has anyone out there done it? -- Danny Wilson IDACOM Electronics danny@idacom.uucp Edmonton, Alberta alberta!idacom!danny C A N A D A From apollo-request@umix.cc.umich.edu Thu Jul 6 11:31:24 1989 Date: 6 Jul 89 13:11:00 GMT From: oj%apollo.uucp@eddie.mit.edu (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: GPR Colour Maps Message-Id: <4442004a.d5b2@apollo.COM> References: <8907051320.AA03260@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8907051320.AA03260@umix.cc.umich.edu> FERGUSON@TMASL.EXXON.COM writes: > > I know that changing a color map requires that the display is > acquired. Otherwise, you'll get a status error back. True, but this is not a problem in borrow mode. > > The arguments for gpr_$set_color_map(start,num_entries,map,status); > are kind of funny. The 'start' is a long (or 4-byte) integer, the > 'num_entries' is a short (16-bit) integer, the 'map' is an array > of long integers, and status is finally a status_$t, or 4-bytes. Yes. If you're using C and SR10 or later, you can have an easier time with this by using /usr/apollo/include/gpr.h instead of /sys/ins/gpr.ins.c . The .h files have function prototypes (hooray) and allow the compiler to get the data types right, or at least error-check them. > > ... two-byte integers were used whenever possible to save > time (this is my theory, not gospel). I wouldn't sanctify this business by referring to our dirty laundry as "gospel." :-) Your theory is correct, though. Two-byte integers also save some address space. /Ollie Jones (speaking for myself, not necessarily for HP) From apollo-request@umix.cc.umich.edu Thu Jul 6 13:00:45 1989 Date: 27 Jun 89 01:36:04 GMT From: mit%wsclark%nttlab%icot32%kddlab.uucp@uunet.uu.net (Kazufumi-MIT-Mitani) Organization: Div. of Info. Eng., Hokkaido Univ., Sapporo Japan. Subject: KANJI font at X11R3/SR10.1 Message-Id: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Is there anybody out there using the k14 font at X11R3? I used X11R2/SR9.7 befor and kterm worked correctly with the k14 font. But when I replcaed X11R2/SR9.7 with X11R3/SR10.1 it doesn't work well. I made Xapollo of X11R3 on DN3000/SR10.1 with official patch #1-#9 and casey's three patch. Xapollo worked well with the original fonts but I want to use the Japanese 'KANJI' font. So I made k14/a14 font from contriob/fonts/oldx11 and kterm (patched xterm for Japanese font) but it doesn't work. I also tested xfd k14 but it finished with XIO: fatal IO error 32 (Broken pipe) on X server "lid3:0.0" after 3 requests (2 known processed) with 0 events remaining. The connection was probably broken by a server shutdown or KillClient. The same message came out when I tested kterm with the k14 font. Some other site in Japan tested kterm with the k14 font on X11R3/SR10.1 and waited 30 minutes but they did't see any window or error message. What is the problem or did I made a mistake? Please test k14 font on X11R3/SR10.1 and give me some suggestion. Thanx in advance, --- Kazufumi MITANI Div. of Info. Eng., Hokkaido University, Sapporo 060 JAPAN mit@huie.hokudai.ac.jp or mit%huie.hokudai.junet@relay.cs.net From apollo-request@umix.cc.umich.edu Thu Jul 6 17:37:24 1989 Date: Thu, 6 Jul 89 17:08:28 edt From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8907062108.AA04948@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: SR10 print servers I'm thinking of writing a batch of SR10 compatible print servers ... but, what printers are the popular ones in the Apollo community? Any one care to put in their two cents worth? == Dave From apollo-request@umix.cc.umich.edu Thu Jul 6 17:50:25 1989 Date: Thu, 6 Jul 89 17:02:54 edt From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8907062102.AA04918@richter.mit.edu> To: apollo@umix.cc.umich.edu, danny%idacom%alberta%ncc%pyramid%amdahl.uucp@ames.arc.nasa.gov Subject: Re: SR10 Installation Unless you can boot a system from the Danford cartridge tape, I'd say he is correct. You need at least one machine which has a floppy or cartridge tape that you can boot from in order to do the initial SR10 installation. However ... I have heard tell of Apollo field service personel who have a complete DN3500 in a suitcase (disk drive and all) -- they simply bring it into you computer room, hook it to your network, and they have a complete system which is known to working correctly and that has a clean copy of the OS (in case all of yours got trashed). If this is true, they good bring a working SR10 machine into your site and load up one of your disks over the network. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Thu Jul 6 23:27:53 1989 Date: Thu, 6 Jul 89 21:07:06 CDT From: Andrew M. Wescott Message-Id: <8907070207.AA01166@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu, krowitz@richter.mit.edu Subject: Re: SR10 print servers We would definitely like to have support for a 300 or 600 series Printronix. The SR 10 prsvr info says these printers are supported, but the existing Apollo drivers do not seem to work with any available AT bus parallel or serial cards. I would think someone out there must have a Printronix hanging off a newer Apollo though. Andrew Wescott University of Houston From apollo-request@umix.cc.umich.edu Fri Jul 7 01:25:31 1989 Date: 6 Jul 89 16:45:11 GMT From: samit%demon%siemens.uucp@princeton.edu (Ben Samit) Organization: Siemens Research and Technology Laboratories Subject: vt100 woes Message-Id: <11406@siemens.siemens.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Scenario: Like most others, I have been having serious problems with rlogin and the vt100 emulator under sr10.1 . I have an open call to the response center but have seen little results. So I ftp'd screen2 from an archive site. It wouldn't compile due to a C-compiler feature. I changed the order of some include files. It compiled but would not run. I ftp'd the original screen (version 1), played with the order of the include files. It compiled and ran. It also hung just as badly as the vt100 emulator. hmm... maybe rlogin is busticated, not the emulator. I am now running telnet instead of rlogin under the vt100 window. It hasn't hung yet. Conclusion: rlogin is broke (or so it seems to me). Some info: running sr10.1, bsd4.3, csh can hang my vt100 window every time by rlogging into our vax and running emacs. The vt100 emulator hangs on exit of emacs, as does screen. Neither hangs when connecting with telnet instead of rlogin. Hope this helps someone, BS | "It's a jelly" - Bob McKenzie | | ARPA: samit@siemens.siemens.com uucp: ..!princeton!siemens!samit | | snail: Siemens SCR 755 College Rd East Princeton, NJ 08540-6668 | | These opinions are solely mine and in no way reflect those of my employer. | From apollo-request@umix.cc.umich.edu Fri Jul 7 01:27:48 1989 Date: 7 Jul 89 04:16:54 GMT From: sahayman@iuvax.cs.indiana.edu (Steve Hayman) Organization: Computer Science Department, Indiana University Subject: Re: vt100 woes (really rlogin problems) (and a kludge fix) Message-Id: <23016@iuvax.cs.indiana.edu> References: <11406@siemens.siemens.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >running sr10.1, bsd4.3, csh >can hang my vt100 window every time by rlogging into our vax and running >emacs. The vt100 emulator hangs on exit of emacs, as does screen. We noticed this too. You can get around most of the problems by using "rlogin -8" instead of "rlogin", but there are still a few other ways to make rlogin hang. If you have the rlogin source (you can ftp it from uunet.uu.net) you can make a small patch to give you a more reliable version of rlogin. The fix is to have the variable "eight" always set, and throw in a "0" into one if-statement in the oob() routine to keep the TIOCPKT_FLUSHWRITE code from being executed. Change int eight; to int eight = 1; and find the line that says: if(mark & TIOCPKT_FLUSHWRITE) { and change it to if ( 0 & mark & TIOCPKT_FLUSHWRITE ) { to disable that part of the oob() code. I'm not sure exactly what the ramifications of disabling this are, but the stock Apollo rlogin hangs in the 'for' loop just after this line, waiting to read data that's never going to arrive. We made the above fix to our rlogin months ago and it hasn't hung since. Hope this is of some use to someone. ..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 Fri Jul 7 07:29:16 1989 Date: 7 Jul 89 06:52:49 GMT From: thallem%guille.uucp@cs.orst.edu (Mike Lohmeyer) Organization: Oregon State University, E&CE, Corvallis Subject: Re: su Message-Id: <11526@orstcs.CS.ORST.EDU> References: <8907011801.AA09885@lnic1.hprc.uh.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8907011801.AA09885@lnic1.hprc.uh.edu> wescott@LNIC1.HPRC.UH.EDU writes: >Well basically I'm a tyrant, as I don't let anyone have SU >privilege. That's one solution! > The idea of the group wheel is for people who are suppose to have access to some system admin stuff. In otherwords, wheel members can sometimes modify files or run programs for system administration that regular users cannot. Wheel is sort of a support group. My solution to the problem was to not use su at all. I don't like the program because sometimes I don't trust the way it sets up the enviroment (home dir, etc.) Instead, I got the sources for su2 from our Microvax II and compiled if the the Apollo systems. For those that don't know, su2 is very similar to su in that it allows users to become root. The difference is that when the user types su2, they are asked to enter their own password, not the root password. That way, no users except the real superuser know the root password. The other nice part about su2 is that the only people who can do an su2 are the users who's names are entered in a file called super-users. These names can be added or removed at any time easily to grant or revoke super user access to users. I should say that I am using SR9.7, not 10.x. I don't know if 10.x has su2 as a standard part of the OS. If not, it should. Su2 is a fairly standard program, and invaluable too. Mike Lohmeyer thallem@ece.orst.edu Oregon State University (503) 645-5504 Electrical and Computer Engineering Department From apollo-request@umix.cc.umich.edu Fri Jul 7 11:30:33 1989 Date: 7 Jul 89 13:17:06 GMT From: leight%neptune%amdcad.uucp@ucbvax.Berkeley.EDU (Tim Leight) Organization: Advanced Micro Devices, Inc., Austin, Texas Subject: Wanted: /usr/ucb/biff like program Message-Id: <1026@neptune.AMD.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Has anyone modified/duplicated /usr/ucb/biff to work with Unix mail on Apollos? thanks in advance tim leight 512-462-5456 From apollo-request@umix.cc.umich.edu Fri Jul 7 13:31:48 1989 Date: Fri, 7 Jul 89 10:16:18 CDT From: Andrew M. Wescott Message-Id: <8907071516.AA01949@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu Subject: C-Shell limit command Could someone tell me how to put limits on cputime and filesize that apply to all my users. I have tried to set limits and hard limits with the C-Shell limit command, but they are not inherited from one window to the next, and they don't affect other users. I imagine there must be something that I can put in the /etc/rc startup files. The machine in question is a DN10000 running SR 10.1. Thanks, Andrew Wescott University of Houston From apollo-request@umix.cc.umich.edu Fri Jul 7 15:35:56 1989 Date: 7 Jul 89 16:07:00 GMT From: oj%apollo.uucp@eddie.mit.edu (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: GPR Colour Maps Message-Id: <4447a4f4.208ba@apollo.COM> References: <8907051320.AA03260@umix.cc.umich.edu>, <4442004a.d5b2@apollo.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Herr Koenigsson followed up with me privately asking why it was better to use .h files than .ins.c files. Here's my answer: You should try to use .h files whenever possible, not just for GPR, but for all Domain/OS Aegis-style system services. First of all, these *.h files are only available at SR10 or later. So, if you are using an SR9.7 or earlier system release, pay no attention to this posting. Let's compare a call, for example gpr_$set_color_map, as it is described in /sys/ins/gpr.ins.c and /usr/apollo/include/gpr.h In gpr.ins.c, the call is described with the single line std_$call void gpr_$set_color_map (); In gpr.h, it is described as follows: extern void gpr_$set_color_map ( gpr_$pixel_value_t & start_index, /* index of first entry */ short int & n_entries, /* # of entries */ gpr_$color_vector_t v, /* entry values */ status_$t * status); /* returned status */ Notice that there's no description of the data types of parameters to the call in gpr.ins.c. It is left completely up to the programmer to get the data types right when making the call. The "std_$call" declaration instructs the compiler to structure the call frame as necessary for calling a Pascal routine. (GPR, and lots of other Domain/OS system software, is written mostly in Pascal.) In gpr.h, on the other hand, each parameter to the call is described explicitly, because we use ANSI C-style function prototypes. For example, let's look at the first paramter. gpr_$pixel_value_t & start_index, /* index of first entry */ The "gpr_$pixel_value_t" declares the data type of the item. The "&" (which is NOT part of ANSI C) declares that the item is passed by reference (that is, the item's address, not its value, is placed in the call frame). "&" has the same effect as declaring a parameter "IN" in Pascal. Some of the items have a "*" rather than a "&". These parameters are explicitly declared to be pointers to data types (the equivalent of "IN OUT" in Pascal). The "start_index" is the name of the parameter. The presence of this function prototype in the gpr.h file allows the compiler to typecheck the parameters you pass to procedures. This saves much trouble. Furthermore, the PRISM (DN10000) C compiler is capable of passing parameters of type float and double in floating-point registers, but only if it can tell (by the presence of the function prototype) that the parameters are indeed floating-point numbers. This is good for performance. You do have to do some code-conversion to switch over to .h files. Primarily, you have to make sure that you're explicitly passing pointers for all the "*" parameters. The old std_$call convention didn't require this. We typically don't convert old (working) code, but we do use .h files for all new C-language development. A side point: If you don't install Aegis when installing SR10, you don't get the .ins.c (or .ins.ftn or .ins.pas files). You do get the .h files, however. You also get the libraries, just not the header files. (Please save your napalm and don't flame us for this, we already know it's a big inconvenience.) Regards, /Ollie Jones (speaking for myself, not necessarily for HP) From apollo-request@umix.cc.umich.edu Fri Jul 7 17:33:11 1989 Message-Id: <8907072007.AA20624@umix.cc.umich.edu> Date: Fri, 7 Jul 89 16:02 EDT From: FERGUSON%TMASL.EXXON.COM@CUNYVM.CUNY.EDU Subject: External Hard Drives To: apollo@umix.cc.umich.edu X-Vms-To: APOLLO My Apollo sales rep just told me that a 700 MB external winchester drive would cost me $14,000 list. That seems a little steep to me, so does anyone have any recommendations for an external 5 1/4" winchester drive to plug into the AT-Bus? Any notes on how much I/O performance is lost by using another vendor? How much (if any) transparency is lost? And the big question...How much MONEY would I save?-) Thanks, Scott Ferguson ferguson@erevax.bitnet From apollo-request@umix.cc.umich.edu Fri Jul 7 17:36:19 1989 Date: 7 Jul 89 13:53:22 GMT From: jhma%harrier.ukc.ac.uk%ukc%mcvax.uucp@uunet.uu.net (James Aldridge) Organization: Solid State Logic, Begbroke, Oxford, OX5 1RU, UK Subject: Re: SR10 Installation Message-Id: <1745@harrier.ukc.ac.uk> References: <701@idacom.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <701@idacom.UUCP> danny@idacom.UUCP (Danny Wilson) writes: >Our [new] sys_admin has been saying that it is impossible to install >SR10 (with Mentor SW) > >We have: > a bunch of DN3000's with NO tapes, > a DSP90 with attached > 300 Meg drive > Danford cartridge tape > 9 track tape > The problem as I understand it is as follows: SR10 requires the disk to be INVOLed which means booting diskless off removable media. Apollos will only boot of floppy or cartridge (DNxxxx only) and not off 1/2 inch Mag tape. >Is it true that we cannot load SR10 with this configuration? >Has anyone out there done it? In this country, Mentor are offering to come on site with an SR10 node and do the initial installation from that. Once ONE node in the network is at SR10, the others can be booted across the network from that node. Subsequent installations can then be done from mag tape or cartridge from your DSP. > >-- >Danny Wilson James Aldridge -- James Aldridge, Solid State Logic,| Any opinions expressed in the above Begbroke, Oxford, OX5 1RU. | article are not necessarily those of E-Mail: jhma@ukc.UUCP | Solid State Logic who employ me or of Telephone: +44 0865 842300 ext.107| UKC who kindly give me network access. From apollo-request@umix.cc.umich.edu Fri Jul 7 17:37:08 1989 Date: 7 Jul 89 11:29:54 GMT From: dh%harrier.ukc.ac.uk%ukc%mcvax.uucp@uunet.uu.net (D.Howard) Organization: Computing Lab, University of Kent at Canterbury, UK. Subject: Wanted: X11R3 bug fixes for the Apollo. Message-Id: <1743@harrier.ukc.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I have obtained a version of X11R3, and am attempting to use it on an apollo running SR9.7 (soon to be upgrading to SR10.1). Could anyone who has a fix for the bugs in the server - and other parts of the release if possible - please let me know what they are. I would be particularly interested in any `official' patches. From apollo-request@umix.cc.umich.edu Sat Jul 8 03:31:20 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8907080700.AA02227@icaen.uiowa.edu> Date: Sat, 8 Jul 89 02:00:13 CDT Subject: install problem To: apollo@umix.cc.umich.edu How do I make the sr10 "install" tool respect my initial default ACLs? I have "closed" systems with "Aegis" style ACLs for the system directories (such as /sys & /lib). Entries in the "baseline" file are: Set acl closed Set never_asked1 N/A Set acl_style aegis I have some optional products that I now want to install, such as gmr3d & phigs. I went thru the sequence of cfgsa, config, and install. When I got done, the ACLs on the new files had nothing to do with the inital default ACLs on their directories. Here are the ACLs that I have for "/lib": $ acl /lib -all Acl for /lib: Required entries root.%.% prwx- %.sys_admin.% prwxk %.%.none [ignored] %.%.% -r-x- Extended entry rights mask: ----- Initial (default) acl for directories created under /lib Required entries For the current process: root.%.% prwx- %.sys_admin.% prwxk %.%.none [ignored] %.%.% -r-x- Extended entry rights mask: ----- Initial (default) acl for files created under /lib Required entries For the current process: root.%.% prwx- %.sys_admin.% pr-xk %.%.none [ignored] %.%.% -r-x- Extended entry rights mask: ----- Here is the ACL on "phigslib" after install put it in /lib: $ acl /lib/phigslib Acl for /lib/phigslib: Required entries root.%.% prwx- %.staff.% prwx- %.%.none prwx- %.%.% prwx- Extended entry rights mask: ----- Is this a bug or a "feature"? Dave Funk From apollo-request@umix.cc.umich.edu Sat Jul 8 08:35:33 1989 Date: 8 Jul 89 04:58:52 GMT From: zoot%cup.portal.com%portal.uucp@uunet.uu.net (David Scott Hardin) Organization: The Portal System (TM) Subject: Adding third party boards to an AT bus machine Message-Id: <20215@cup.portal.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I have a (mad) friend who wants to stick some third party boards into an AT bus Apollo (something weird like a 1553 bus interface gizmo originally used in a "real" PC/AT). What are the best sources of information for such an undertaking (device drivers required, Apollo-reserved interrupts, memory map problems, etc.)? Anybody out there got any good war stories? Target system: DN3500, SR9.7.1 David Hardin Rockwell International Collins Government Avionics Division zoot@cup.portal.com hardin@eecea.eece.ksu.edu From apollo-request@umix.cc.umich.edu Sun Jul 9 07:38:16 1989 Date: 7 Jul 89 19:35:15 GMT From: paul%bcsfse%voodoo%ssc-vax.uucp@beaver.cs.washington.edu (Paul Hardiman) Organization: bcs Subject: Single /etc dir Message-Id: <356@bcsfse.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Looking for feedback from anybody who may have pioneered what I am about to do. I am considering combining the /etc directories of both Sys5 and BSD4.x. /etc. The proposed layout looks as follows: # ls -dlS /sys5/etc /bsd4.2/etc /etc lrwxrwxrwx 1 5 Feb 2 10:17 /bsd4.2/etc -> /,etc lrwxrwxrwx 1 root bin_sr9 14 Apr 24 13:12 /etc -> $(SYSTYPE)/etc lrwxrwxrwx 1 5 Feb 2 10:16 /sys5/etc -> /,etc These seems to satisfy the expectations of the installation procedures. But what I am really interested in is the caveats of a combined /etc. Thanks-- Paul Hardiman ...!uw-beaver!ssc-vax!voodoo!bcsfse!paul The above views are strictly my own. ============================================================ From lubkin@apollo.com Mon Jul 10 08:22:19 1989 From: David Lubkin Message-Id: <8907101311.AA12066@xuucp.ch.apollo.com> Date: Mon, 10 Jul 89 08:50:56 EDT Subject: INFO-DSEE mail To: dsee_list:@apollo.com Date: fri, 7 jul 89 11:24:13 From: conliffe@caen.engin.umich.edu (Darryl C. Conliffe) Subject: Can't remember the answer to 10.1.p There was some discussion a while back on a problem encountered when trying to load dsee 3.3.2 on an SR 10.1 node. The install would fail with ERROR:For product apollo.dsee: apollo.os version 10.1.p was not found RAI install has aborted with errors Can anyone enlighten me on how to get around this message? - Darryl (313) 721-6069 ------- From daigle@apollo.com Mon Jul 10 09:29:57 1989 From: Joe Daigle Message-Id: <8907101352.AA12665@xuucp.ch.apollo.com> Date: Mon, 10 Jul 89 09:28:56 EDT Subject: Re: INFO-DSEE mail To: lubkin@apollo.com Cc: daigle@apollo.com, molly_s@apollo.com, rodan@apollo.com, bazelmans@apollo.com, dsee_list:@apollo.com In-Reply-To: lubkin, mon, 10 jul 89 08:50:56 Yes, There is a tool /install/tools/fix_10_1_ri which needs to be run which will fix the problem. Running this tool should solve the problem. If this problem persists, please call Customer Service. ~jwd Date: fri, 7 jul 89 11:24:13 From: conliffe@caen.engin.umich.edu (Darryl C. Conliffe) Subject: Can't remember the answer to 10.1.p There was some discussion a while back on a problem encountered when trying to load dsee 3.3.2 on an SR 10.1 node. The install would fail with ERROR:For product apollo.dsee: apollo.os version 10.1.p was not found RAI install has aborted with errors Can anyone enlighten me on how to get around this message? - Darryl (313) 721-6069 ------- Joseph W. Daigle Apollo Computer A Subsidiary of Hewlett-Packard MS CHA-01-LT 508/256-6600 x6248 15 Elizabeth Drive ARPA: daigle@apollo.com Chelmsford, MA 01824 UUCP: {decwrl!decvax, mit-eddie, attunix}!apollo!daigle ------- From lubkin@apollo.com Mon Jul 10 09:30:16 1989 From: David Lubkin Message-Id: <8907101351.AA12647@xuucp.ch.apollo.com> Date: Mon, 10 Jul 89 09:08:14 EDT Subject: INFO-DSEE mail To: dsee_list:@apollo.com Date: mon, 10 jul 89 09:16:00 From: derstad@cim-vax.honeywell.com ("DAVE ERSTAD") Subject: DSEE Difficulties This is being cross-posted to dsee-list and info-apollo; I'm not sure if the membership is a complete overlap. Here's a laundry list of DSEE problems Apollo didn't tell you about... (Or at least didn't tell *me* about). Most are various version compatibility problems. 1) DSEE 3.2.1 is supposed to be compatible with SR9.7 or later. Actually, you need SR9.7.0.4 or later. If you are running 9.7.0.3, the D3M server will abort with a message telling you that the node is not at 9.7 or later. This is due to some naming call added at 9.7.0.4 which needs to be present. 2) DSEE 3.3.1 does not appear to be as compatible with 3.2.1 as advertised. Specifically, we have found that if one has a DSEE shell node at 9.7 DSEE builder node at 10.0 DSEE reference node at 9.7 OR DSEE shell node at 10.0 DSEE builder node at 9.7 DSEE reference node at 9.7 then DSEE is sometimes (possibly always; I just can't prove/disprove that) unable to locate derived objects from previous builds for use in current builds (our specific derived objects are insert files for Pascal applications). This is not a case sensitivity problem, and we do have DOWNCASE set in the ENVIRONMENT section. It should be noted that this problem disappears with DSEE 3.3.2.p, and presumably with DSEE 3.3.2 although we don't have that yet. 3) The compiled models used by 3.3.2.p are not compatible with 3.2.1. Presumably, this also means 3.3.2 is not compatible with 3.2.1, although again we haven't verified that. Dave Erstad Principal DA Engineer Honeywell SSEC ------- From apollo-request@umix.cc.umich.edu Mon Jul 10 11:00:08 1989 Date: Mon, 10 Jul 89 08:53:42 edt From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8907101253.AA01595@richter.mit.edu> To: apollo@umix.cc.umich.edu, zoot%cup.portal.com%portal.uucp@uunet.uu.net Subject: Re: Adding third party boards to an AT bus machine You will want a copy of the "Writing Device Drivers with GPIO" manual. The SR9.7 GPIO release tapes come with a number of sample drivers which are installed in the /domain_examples directory. Apollo has these "CPU configuration" worksheets (actually little cardboard cards) which list the reserved interrupt lines and device addresses for each of the different CPU types and the various standard Apollo devices. You can probably get a copy from your field service personnel. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Mon Jul 10 17:36:57 1989 Message-Id: <8907102104.AA19984@umix.cc.umich.edu> Date: 10 Jul 89 15:34:00 CST From: "DAVE ERSTAD" Subject: DSEE Difficulties To: "apollo" This is being cross-posted to dsee-list and info-apollo; I'm not sure if the membership is a complete overlap. Here's a laundry list of DSEE problems Apollo didn't tell you about... (Or at least didn't tell *me* about). Most are various version compatibility problems. 1) DSEE 3.2.1 is supposed to be compatible with SR9.7 or later. Actually, you need SR9.7.0.4 or later. If you are running 9.7.0.3, the D3M server will abort with a message telling you that the node is not at 9.7 or later. This is due to some naming call added at 9.7.0.4 which needs to be present. 2) DSEE 3.3.1 does not appear to be as compatible with 3.2.1 as advertised. Specifically, we have found that if one has a DSEE shell node at 9.7 DSEE builder node at 10.0 DSEE reference node at 9.7 OR DSEE shell node at 10.0 DSEE builder node at 9.7 DSEE reference node at 9.7 then DSEE is sometimes (possibly always; I just can't prove/disprove that) unable to locate derived objects from previous builds for use in current builds (our specific derived objects are insert files for Pascal applications). This is not a case sensitivity problem, and we do have DOWNCASE set in the ENVIRONMENT section. It should be noted that this problem disappears with DSEE 3.3.2.p, and presumably with DSEE 3.3.2 although we don't have that yet. 3) The compiled models used by 3.3.2.p are not compatible with 3.2.1. Presumably, this also means 3.3.2 is not compatible with 3.2.1, although again we haven't verified that. Dave Erstad Principal DA Engineer Honeywell SSEC From apollo-request@umix.cc.umich.edu Tue Jul 11 01:08:51 1989 Date: 10 Jul 89 22:29:35 GMT From: weiner%novavax%uflorida%rex.uucp@g.ms.uky.edu (Bob Weiner) Organization: Nova University, Fort Lauderdale, FL Subject: Re: vt100 woes Message-Id: <1374@novavax.UUCP> References: <11406@siemens.siemens.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu > So I ftp'd screen2 from an archive site. It wouldn't compile due to a > C-compiler feature. > > Some info: > running sr10.1, bsd4.3, csh I've had the same problem as Bob using screen2 under the same SR10.1 environment. Anyone care to comment on how to actually get it to work? -- Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner (407) 738-2087 From apollo-request@umix.cc.umich.edu Tue Jul 11 14:14:46 1989 Date: 11 Jul 89 15:47:00 GMT From: kumorek%apollo.uucp@eddie.mit.edu (James Kumorek) Organization: Apollo Computer, Chelmsford, Mass. Subject: Re: Apollo ANSI standard C? How close? Should it matter? Message-Id: <445bb0a6.19451@apollo.COM> References: <8906271541.AA06634@scrolls.wharton.upenn.edu>, <4203@hacgate.scg.hac.com>, <6732@sdcsvax.UCSD.Edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <2821 of comp.sys.apollo> markley@net1.ucsd.edu writes: > >I'm not sure how much of the viewgraphs Jim Kumorek of Apollo passed out > >at the Sys Admin Conference in San Diego apply to C, but I'll try to > >weed out appropriate notes. Hope this helps. > > > lot of stuff deleted... > > > >4. Current gotcha: object files don't pass through NFS gateways > > > > at 10.2, object files will pass through gateways > > > > This is not entirely true. The compilers will not write object > files through an NFS gateway. The linker will. Also if you > copy an object file onto an NFS volume it is executable by the > Apollo workstation. You can put a work-around to this problem > by specifying an -o /tmp/ to the cc line and then copying > this file to your current directory and linking it. This is > what I did and I don't have any problems. Note that the original message said that it was the next release of the compilers, not a current release, that will enable the compilers to write thier binaries over NFS links. Jim Kumorek Apollo Computer kumorek@apollo From apollo-request@umix.cc.umich.edu Wed Jul 12 17:26:26 1989 Date: 12 Jul 89 03:22:09 GMT From: kts%quintro%tiamat.uucp@uunet.uu.net (Kenneth T. Smelcer) Organization: none Subject: Re: vt100 woes Message-Id: <1989Jul12.032209.2072@quintro.uucp> References: <11406@siemens.siemens.com>, <1374@novavax.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1374@novavax.UUCP> weiner@novavax.UUCP (Bob Weiner) writes: >> So I ftp'd screen2 from an archive site. It wouldn't compile due to a >> C-compiler feature. >> >> Some info: >> running sr10.1, bsd4.3, csh > >I've had the same problem as Bob using screen2 under the same SR10.1 >environment. Anyone care to comment on how to actually get it to >work? >-- >Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner >(407) 738-2087 Here is a patch for screen2 to get it working under SR10.1. The major problem is how screen2 checks to see if another screen process is running. Since my knowledge of TCP/IP is very limited, I just IFDEFed this test and now it works fine. If someone fixes this the right way, please let me know. BTW, this patch assumes your running screen2 with Patrick Wolfe's patches. ========================================================================= *** Makefile Wed Jun 28 10:45:41 1989 --- Makefile Thu Mar 16 00:58:05 1989 *************** *** 5,12 **** PGM = screen BIN = /usr/local/bin ! MS = l ! CFLAGS = -O CFILES = screen.c ansi.c OFILES = screen.o ansi.o --- 5,12 ---- PGM = screen BIN = /usr/local/bin ! MS = 1 ! CFLAGS = -O -DAPOLLO CFILES = screen.c ansi.c OFILES = screen.o ansi.o *** screen.c Wed Jun 28 10:45:39 1989 --- screen.c Thu Mar 16 01:07:51 1989 *************** *** 16,21 **** --- 16,22 ---- static char ScreenVersion[] = "screen 2.1 3-Mar-1989"; #include + #include #include #include #include *************** *** 24,30 **** #include #include #include - #include #include #include #include --- 25,30 ---- *************** *** 1406,1411 **** --- 1406,1413 ---- a.sun_family = AF_UNIX; strcpy (SockNamePtr, SockName); strcpy (a.sun_path, SockPath); + + #ifndef APOLLO if (connect (s, (struct sockaddr *)&a, strlen (SockPath)+2) != -1) { p = Filename (SockPath); Msg (0, "You have already a screen running on %s.\n\ *************** *** 1412,1417 **** --- 1414,1421 ---- If it has been detached, try \"screen -r\".", p); /*NOTREACHED*/ } + + #endif (void) unlink (SockPath); if (bind (s, (struct sockaddr *)&a, strlen (SockPath)+2) == -1) Msg (errno, "bind"); -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ken Smelcer Quintron Corp. quintro!kts@lll-winken Quincy, IL tiamat!quintro!kts@uunet From apollo-request@umix.cc.umich.edu Wed Jul 12 17:26:44 1989 Date: 12 Jul 89 00:59:52 GMT From: snoopy%sopwith%parsely%psueea%tektronix%zephyr.uucp@uunet.uu.net (Snoopy) Organization: The Daisy Hill Puppy Farm Subject: Re: Academic workstations Message-Id: <244@sopwith.UUCP> References: <5386@rpi.edu>, <8732@venera.isi.edu>, <2467@internal.Apple.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <2467@internal.Apple.COM> fair@apple.com (Erik E. Fair) writes: |Just try getting Ultrix source from DEC. When you do, you'll find out that |it is "for reference purposes only." | Erik E. Fair apple!fair fair@apple.com Presumably this implies that Apple supplies full source code for all its offerings. _____ .-----. /_____\ Snoopy ./ RIP \. /_______\ qiclab!sopwith!snoopy | | |___| parsely!sopwith!snoopy | tekecs | |___| sun!nosun!illian!sopwith!snoopy |_________| "But we're only up to the fourth inning." From apollo-request@umix.cc.umich.edu Wed Jul 12 17:27:11 1989 Date: 11 Jul 89 22:05:00 GMT From: conliffe%caen.engin.umich.edu%mailrus.uucp@g.ms.uky.edu (Darryl C. Conliffe) Organization: U of M Engineering, Ann Arbor, Mich. Subject: psprint Message-Id: <445d0270.b11a@falcon.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Danford used to market a product called psprint. They no longer market it. Does anyone know who might? -- ___________________ Darryl C. Conliffe conliffe@caen.engin.umich.edu (313) 721-6069 ------------------- From apollo-request@umix.cc.umich.edu Wed Jul 12 17:27:15 1989 Date: 11 Jul 89 20:33:03 GMT From: keith%sequoia%execu%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Keith Pyle) Organization: Execucom Systems Corp. Subject: Hardware prices Message-Id: <585@sequoia.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We are trying to determine a reasonable price for the following used hardware: DN3000 with 348 meg disk and 19" monochrome monitor DN3000 without disk, 19" monochrome monitor If you have bought or sold either of these recently or know of approximate prices for them (or similar configurations), I would like to hear from you. Thanks. -- ----------------------------------------------------------------------------- Keith Pyle UUCP: ...!cs.utexas.edu!execu!keith Execucom Systems Corp., Austin, Texas Internet: execu!keith@cs.utexas.edu keith%execu.uucp@cs.utexas.edu Disclaimer: What?? You actually believed me? ----------------------------------------------------------------------------- From apollo-request@umix.cc.umich.edu Wed Jul 12 17:27:50 1989 Date: 11 Jul 89 15:39:00 GMT From: kumorek%apollo.uucp@EDDIE.MIT.EDU (James Kumorek) Organization: Apollo Computer, Chelmsford, Mass. Subject: Re: Apollo ANSI standard C? How close? Should it matter? Message-Id: <445ba95c.19451@apollo.COM> References: <8906271541.AA06634@scrolls.wharton.upenn.edu>, <4203@hacgate.scg.hac.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu > 1. CC will be "fully ANSI compliant by the release following the > next release," i.e., the release after SR10.2 > > includes const, signed, volatile These features are due out in the next release of the compilers, sometime this fall (The exact date is yet to be determined). > 2. SR10.2 is "due out in September/October." Note that the compilers, as of this release, are no longer being shipped with the OS releases; they have been 'unbundled'. Therefore, the release of the compilers this fall has nothing to due with the release of SR10.2. - Jim Kumorek From apollo-request@umix.cc.umich.edu Wed Jul 12 17:36:58 1989 Date: 12 Jul 89 16:39:10 GMT From: lori%hacgate%usc.uucp@BLOOM-BEACON.MIT.EDU (Lori Barfield) Organization: Hughes Aircraft Company, El Segundo CA Subject: Apollos and DOD-Related Security Measures; InterCAP S/W Message-Id: <4349@hacgate.scg.hac.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Is anyone else out there using Apollos for secured government projects? What special steps did you go through to insure security in a "tank" environment? Are there any gotchas you can warn us about? Does UNIX under SR10 offer the "failed login" feature? We plan a heterogeneous network; there will be a stand-alone Apollo as well as a Sun, VAX, and other stuff. The Apollo will not have a Ring card; it will only be fitted for Ether. The Apollo on the net will be dedicated to the InterCAP CAD system. I'm interested in starting a dialogue with other sys admins out there who support the InterCAP application. We have some handy stuff we can share. ...lori From apollo-request@umix.cc.umich.edu Wed Jul 12 17:41:13 1989 Date: 12 Jul 89 18:21:35 GMT From: michal%kuhub.cc.ukans.edu%wupost%wugate.uucp@uunet.uu.net (Merlin The Magician) Organization: University of Kansas Academic Computing Services Subject: VT100 Termcap entry (sf:) Message-Id: <5262@kuhub.cc.ukans.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Our Apollo DN 4000 workstations came with this weird termcap entry for a VT100. (...) :sf=30\E7\E200H\ED\E8 (...) The result is that when using an IBM PC with Kermit 2.31 (emulating a vt100) there is no scrolling forward. A line from a TERMCAP entry for a vt100 from another system (VAX 11/780 BSD 4.3) reads (...) :sf=5\ED (..) Che cos'e' la bella differanza ?! -Merlin +-----------------------------------------------------------------------------+ | Michal Chmielewski K K U U | | Academic Computing Services K K U U | | University of Kansas K K U U | | Lawrence, KS 66045 KK U U | | Internet: michal@kuhub.cc.ukans.edu K K U U | | BitNet : michal@ukanvax.bitnet K K U U | | AT&T : (913)-864-0443 K K UUUUU | +-----------------------------------------------------------------------------+ From apollo-request@umix.cc.umich.edu Wed Jul 12 17:46:57 1989 Date: 12 Jul 89 11:52:56 GMT From: leon_h%euteal%eutrc3%hp4nl%mcvax.uucp@uunet.uu.net (Leon Ham) Organization: none Subject: problems with X colormaps Message-Id: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Problem description: using a private Colormap on Apollo using the Xapollo server. In one of my applications I use a colormap private to this program. Since I neither want to corrupt the domain-windows nor the other running X applications, I only use entries 64 until 253 in my program. To prevent the other applications from vanishing off the screen (by becoming displayed in black) I want to copy all entries from 0 until 63 of the default colormap into my application's private colormap. I do this by calling XQueryColor for all desired pixel values from the XDefaultColormap and storing the retrieved colors into my private colormap with ues of XStoreColor. This works well, except for those entries the domain window manager uses: 0, 1 and 8 until 15. Those entries are protected by the Xapollo server. An XQueryColor call to those entries will result in returning an empty color cell (Black). Initially, I tried to solve the problem by creating the private colormap with XCopyColormapAndFree. This didn't work: the domain entries weren't copied into the private colormap. This gives us reason to believe that the colors in the domain entries are not allocated by the Xapollo server, for if this wasn't true, a call to XQueryColor would return the actual value of the color cell concerned. Here, at the Eindhoven University of Technology, we found a way to prevent the domain entries in the colormap from appearing black by executing the following for every domain entry: XParseColor (Xdisplay, Xdefault_colormap, color_name, &Xcolor); XAllocColor (Xdisplay, Xdefault_colormap, &Xcolor); XStoreColor (Xdisplay, Xcolormap, &Xcolor); where 'color_name' is either the hex-value of the domain color, or the corresponding X name found in /usr/lib/X11/rgb.txt with rgb entries exact those of the domain color. The disadvantage of the approach above is that the application program needs the exact rgb values installed in the domain entries and that there is no way of retrieving them by means of call(s) to any X function. Is there an other approach known outthere, or did we run into a bug of the Xapollo server?? Or did we misunderstand something?? -- +---------------------------------------+---------------------------------------+ | Leon C.G.A.M. Ham | Room EH 7.25 | | Eindhoven University of Technology | P.O. Box 513 | | Department of Electrical Engineering | NL-5600 MB Eindhoven | +---------------------------------------+---------------------------------------+ | Phone: +31 (40) 473345/3238 | Email: leon_h@es.ele.tue.nl | +---------------------------------------+---------------------------------------+ From apollo-request@umix.cc.umich.edu Wed Jul 12 21:34:45 1989 Date: 12 Jul 89 23:26:03 GMT From: apippin%polyslo.uucp@decwrl.dec.com (Pinhead@Spikes) Organization: Viking Tours & Travels Subject: SR9.7 & 10.1 Message-Id: <12476@polyslo.CalPoly.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am about to attempt to bring a DN3550 running 10.1 BSD onto a ring of ten other DN3000 running 9.7 AEGIS. Is there anybody out there that has done this (or is doing this). Any help will be greatly appreciated. a. -- Andy Pippin "Beauty is only a lightswitch away..." apippin@polyslo.CalPoly.EDU "Thirty-one. SOCIAL!!!" From apollo-request@umix.cc.umich.edu Wed Jul 12 23:37:13 1989 Date: 12 Jul 89 23:43:15 GMT From: mcalle%andy%wright%ncrlnk.uucp@uunet.uu.net (Mauricio Calle) Subject: Installing SR10 with UNIX only Message-Id: <588@thor.wright.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I have a simple question for anyone who knows the answer and wants to respond: Can I install the SR10 UNIX environment alone without AEGIS and still run Mentor and NCR tools? Mauricio Calle mcalle@wight.edu :end: From apollo-request@umix.cc.umich.edu Thu Jul 13 05:32:09 1989 Date: 12 Jul 89 16:36:50 GMT From: rchrd%well.uucp@apple.com (Richard Friedman) Organization: RCHRD 2855 Telegraph #415 Berkeley CA 94705 Subject: Stand-Alone nodes and SR10 Installation Procedures... Message-Id: <12670@well.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Having a single DN3000 not attached to anything except a 2400 baud modem requires alot of reading between the lines when installing SR10.1 etc. It is never explicitly stated anywhere in the installation documentation what can be deleted from the installation area and what can't. ALso, I'm sure the installation procedure itself could be greatly simplified for stand-alone nodes. Could someone at Apollo hear this small voice out there in the wilderness, and please include an appendix to the installation notes giving a quick receipe for installing 10.2 (when it comes) on single stand alone nodes. -- ...Richard Friedman rchrd@well.uucp (Pacific-Sierra Research/Berkeley, CA.) also: {lll-crg,pacbell,hplabs}!well!rchrd From apollo-request@umix.cc.umich.edu Fri Jul 14 03:31:20 1989 Date: 14 Jul 89 05:18:07 GMT From: sahayman@iuvax.cs.indiana.edu (Steve Hayman) Subject: Fun with timezones Message-Id: <23344@iuvax.cs.indiana.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I have submitted this as an APR but thought others might be interested. Indiana is on Eastern Standard Time year round, and I cannot seem to use "tz" to set the timezone to "EST" without having it assume I also want "EDT". (Actually I can get it to work but the method is a hack, see below.) (If there's a better way, someone please let me know.) An annotated listing of my attempts follow. The idea is to use "tz" on the machine "sjohnson" to set the timezone and offset, and then use "rsh sjohnson date" to show what the date is in a brand new context. First try - just use EST: # tz EST; rsh sjohnson date Fri Jul 14 00:39:09 EDT 1989 # no good, assumes you want EDT Hmmm, maybe if we explicitly say what the offset of EST is, as if we were defining a brand new zone: # tz EST -5:00; rsh sjohnson date Fri Jul 14 00:39:31 EDT 1989 # still assumes you want EDT OK, maybe "EST" is in a table of existing time zones somewhere, no problem. Let's try inventing a brand new time zone, "IST", Indiana Standard Time. # tz IST -5:00; rsh sjohnson date Fri Jul 14 00:39:50 IDT 1989 # Where the !@#@*() did "IDT" come from? Hmm, this odd program must be looking up "?ST" in a table and assuming you mean "?DT" when appropriate. Let's try "IUT" instead of "IST": # tz IUT -5:00; rsh sjohnson date Thu Jul 13 23:40:04 IUT 1989 OK, if you give it an unexpected time zone, it seems to believe you. Hmmmm ... What if we give it a zone longer than 3 characters? # tz Eastern -5:00; rsh sjohnson date Thu Jul 13 23:40:29 EAS 1989 Aha! That does almost what we want but we'd like it to say "EST" instead of "EAS", so let's fake it out and use "ESTx" instead of "EST": # tz ESTx -5:00; rsh sjohnson date Thu Jul 13 23:40:44 EST 1989 Success at last - new shells get the TZ and TZNAME variables we wanted all along. # rsh sjohnson printenv ... TZ=EST5 TZNAME=EST, Ideally I'd like to see Apollo adopt the public domain time zone code that many other manufacturers (e.g. Sun) use - this code by Arthur Olson has been posted to the net in the past, and it allows you to define a file giving the time zone rules for your location. SunOS comes with a special "East-Indiana" file which matches our needs exactly. Sure is easier than doing this kind of goofing around. ..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 Fri Jul 14 06:05:25 1989 Date: 14 Jul 89 03:30:36 GMT From: cantrell%attctc.uucp@ames.arc.nasa.gov (Keith Cantrell) Organization: The Unix(R) Connection BBS, Dallas, Tx Subject: Re: vt100 woes Message-Id: <8642@attctc.DALLAS.TX.US> References: <11406@siemens.siemens.com>, <1374@novavax.UUCP>, <1989Jul12.032209.2072@quintro.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1989Jul12.032209.2072@quintro.uucp> kts@quintro.UUCP (Kenneth T. Smelcer) writes: weiner@novavax.UUCP (Bob Weiner) writes: <>> So I ftp'd screen2 from an archive site. It wouldn't compile due to a <>> C-compiler feature. [ ..... stuff deleted .... ] < Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Anyone working with an optical disk backup system they like? Which one? (Apollo node backup.) From apollo-request@umix.cc.umich.edu Fri Jul 14 09:29:50 1989 Date: 13 Jul 89 15:17:40 GMT From: sullivan%msor%expya%warwick%ukc%mcvax.uucp@uunet.uu.net (Rob Sullivan) Organization: MSOR Department, Exeter University, UK Subject: Benchmarks for DN10000? Message-Id: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu My department (theoretical solid state physics) is interested in buying a new machine in the near future. It would be very useful if someone could provide a reliable set of benchmarks for the DN10000, which we would expect to use as a three processor system. Benchmarks for the Stellar DS2500 and DS2000 would also be extremely valuable. Thanks in advance, Rob... From apollo-request@umix.cc.umich.edu Sat Jul 15 03:38:48 1989 Date: 14 Jul 89 18:12:02 GMT From: tomh%sequent%tektronix%zephyr.uucp@uunet.uu.net (Tom Holthaus) Organization: Sequent Computer Systems, Inc Subject: Renting a DN10000 Message-Id: <18729@sequent.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu It seems that renting PC class machines is a very common thing. My question is if it is possible to rent or lease a DN10000 for a small number of months such as 3 or 4? From apollo-request@umix.cc.umich.edu Sun Jul 16 18:10:15 1989 Date: Sun, 16 Jul 89 16:05:42 CDT From: Andrew M. Wescott Message-Id: <8907162105.AA01004@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu Subject: DM fonts We have just upgraded our dn10000 to a 80 plane VS unit. The first thing I noticed was the very small fonts that are loaded by default on the 1280 x 1024 monitor. My DM competence is minimal, but I did an "fl" on the /sys/dm/fonts/std.color fonts in startup_login.1280color, and now the fonts size within the pads is acceptable. But...the fonts in the DM command window at the bottom are still the small ones. I tried to do the same fl in /sys/node_data/startup before the DM window is created, but this didn't help. How do you do this? Andrew Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Mon Jul 17 01:31:17 1989 Date: 15 Jul 89 21:34:00 GMT From: lray%uxh.cso.uiuc.edu%ux1.cso.uiuc.edu.uucp@uxc.cso.uiuc.edu Subject: SR10 prsvr q's Message-Id: <18300011@uxh.cso.uiuc.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hello all... I'm working on a print driver using the new printing facilities at SR10.1. I have so far found the documentation clear and the example clear enough, but I've been having a few problems that I think someone out in netland might be able to help me on. 1. One of the things I wish to be able to do is keep track of who is printing what. The driver can get the source file name from the job_db, but it cannot get the user who printed the file. I tried using prf_$read_queue to get this information to no avail -- prmgr seems to delete the current queue entry before the driver is called. Does anyone have a good solution to this? I've APRed it in, but any information that will let me complete my work would be highly appreciated. 2. It seems the documemtation for the databases is messed up. The manual mentions an object called config_db that lists parameters specified in the configuration file for prsvr. However, the header file /sys/ins/prsvr.ins.c suggests that it is called control_db. However, trying to examine it yields an execution error. Does anyone know what what is wrong? I need more than the interface parameters. Thanks for all answers in advance. lray@civilgate.ce.uiuc.edu Leland Ray, Department of Civil Engineering University of Illinois at Urbana-Champaign (217) 333-3821 From apollo-request@umix.cc.umich.edu Mon Jul 17 13:48:29 1989 Date: 17 Jul 89 14:53:43 GMT From: hidinger%peanuts.nosc.mil.uucp@nosc.mil (Ron Hidinger) Organization: Naval Ocean Systems Center, San Diego Subject: Re: Benchmarks for DN10000? Message-Id: <1376@nosc.NOSC.MIL> References: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I don't know how reliable these benchmarks are but here are some results obtained with a single cpu loaner from the local office. Not sure how much memory it had, but swapping was not a factor. Time was measured using /bin/time, except the graphics benchmark. Ron Hidinger hidinger@nosc.mil -------------------------------------------------------------- The results are in seconds. The numerical integration involves single and double precision floating point for the most part. The FFT's are single precision. The beam pattern involves a 2 dimensional FFT and false color intensity plot, about 5000 trapezoids. This was a single processor machine with the extra graphics hardware. The pascal compiler was used which according to the salesman is already one revision behind. HOST solve 6 DOF PDE FFT's 2D beam pattern ------- --------------- ----- --------------- DN300 -- DN320 105.8 DN330 59.0 DN460 44.1 DN3000 60.6 DN3000 (SR9.6) 53.5 DN4000 25.9 DN3500 18.6 26.5 ~16 DN3550 18.9 DN4500 13.2 DN10000 1.3 2.9 ~4 From apollo-request@umix.cc.umich.edu Mon Jul 17 21:37:35 1989 Date: 17 Jul 89 16:23:46 GMT From: turner%dover%oakhill%cs.utexas.edu%natinst%bigtex%texbell%texsun%sun-barr.uucp@apple.com (Robert Turner) Organization: Motorola Inc., Sector CAD, Mesa, AZ Subject: Re: Benchmarks for DN10000? Message-Id: <1589@dover.sps.mot.com> References: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article , sullivan@msor.exeter.ac.uk (Rob Sullivan) writes: > reliable set of benchmarks for the DN10000, First there is no such animal as a "reliable set of benchmarks". But to answer your question, we have seen from 4 to 15 times faster wall clock times than a DN4000. Our DN10k is a multi-processor, four CPUs. When running three jobs in parallel each job ran less than 10% longer on wall clock time. Note all programs and all data resided in the single DN10K's disk. Your real question should be what will be the easiest machine to use in our Apollo environment. The answer hands down is a DN10K. For us, it was a plug and play, and on the ring in a couple of days (due to newness of SR10). Robert From apollo-request@umix.cc.umich.edu Mon Jul 17 23:35:38 1989 Message-Id: <8907180304.AA24423@umix.cc.umich.edu> Date: 17 Jul 89 21:46:00 CST From: "DAVE ERSTAD" Subject: DSEE Compatibility issues To: "apollo" At least one of the DSEE compatibility issues I previously reported, inability to access derived objects in subsequent builds, has been identified as an undocumented version dependency on the Pascal compiler. If you're working in a mixed 9.7/10.1 environment, I suggest you make sure your SR9.7 compiler is at 7.54 or later. I understand that Apollo can't test every combination of everything with everything else, but it would help if they would document the earliest rev level they tested (i.e. We verified mixed network builds using aegis 9.7.0.4/SR10.1, Pascal xxx.xxx/xxxx.xxx, etc.). This is about hte fourth (depends on how you count them) undocumented version dependency I've encountered with the DSEE software and some aspect of the migration and its terribly frustrating to waste three weeks trying to resolve something like this. From apollo-request@umix.cc.umich.edu Tue Jul 18 13:48:56 1989 Date: 17 Jul 89 18:23:19 GMT From: rchrd%well.uucp@hplabs.hp.com (Richard Friedman) Organization: RCHRD 2855 Telegraph #415 Berkeley CA 94705 Subject: SR10.1 Installation Procedure ! Message-Id: <12735@well.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Due to a unending series of hardware problems that resulted in the hard disk on my stand alone DN3000 being replaced twice, I have had to install and re-install SR10.1 over 4 times in the past two weeks! Anyone who has had to do this installation (from cartridge tapes) only once knows of what intrepedations I speak. Now, while my DN3000 is at the Apollo shop, I have time to reflect on the deficiences of the SR10 installation procedure and give some recommendations, if anyone at Apollo is there to listen.. These comments are particularly targetted at the single, stand alone system. 1. There needs to be a load/install option for the stand alone system. In particular, there should be a clean-up procedure that deletes unneeded parts of the software from the disk. Also, the installation procedure could be smarter and not bother to load unneeded system files. I have noticed that even tho only one SAU option is selected, MINST loads all the SAU directories into the AA. Why? Information about the parts of the system the user does not want (such as /usr/games, /usr/new, domain_examples, unneeded manual pages, etc.) should be requested at the start and skipped from the load process as well as the install. 2. Documentation of the load/install is terrible! The "Installing Software" manual should have been re-issued with corrections rather than having the corrections in the release notes. In the end, the messages that come out of MINST and INSTALL++ during installation don't correspond to anything in either document. This adds great anxiety when you are 2 hours into the installation and a question comes up that you don't know how to answer. The documentation should be clearer on what happens when you answer questions on the screen. All answers should be mentioned. 3. Once the system is installed, there should be a backup procedure that will transfer the system, with a boot record, to a backup medium, like cartridge tape, so that should the disk have to be INVOL'd later on we can re-load the system without having to go thru the whole load/install procedure again! This seems simple enough to do. A system backup builder can look around to see what is installed on the disk, prepare a bootable tape in whatever structure it needs, and write the tape(s). Later, after an INVOL, a RELOAD from the monitor shell should be able to put everything back and setup for a boot back to DOMAIN_OS. Were this system backup/reload available I could have saved at least 25 hours of real agony! 4. Finally, I have noticed that the load procedure at times will retension a cartridge tape twice! Retensioning should be a y/n option from the console and be global: "Should load volumes be retensioned before being read [y/n]" If this is the second re-install today, I really don't think I have to retension and would like to skip it. Lets hope SR10.2 looks better. And don't forget about us stand alone sites, please! -- ...Richard Friedman rchrd@well.uucp (Pacific-Sierra Research/Berkeley, CA.) also: {lll-crg,pacbell,hplabs}!well!rchrd From apollo-request@umix.cc.umich.edu Tue Jul 18 15:57:47 1989 Date: 18 Jul 89 02:53:10 GMT From: joshua%athertn%hpda.uucp@ucbvax.Berkeley.EDU (Flame Bait) Organization: Atherton Technology, Sunnyvale, CA Subject: A comparison of Commercial RPC Systems Message-Id: <6569@joshua.athertn.Atherton.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I've finished work on a paper entitled "A Comparison of Commercial RPC Protocols" which I gave at NCF: The Network Computing Forum, and also as a work in progress at USENIX. It compares RPC (Remote Procedure Call) systems from Apollo, Sun and Netwise for speed and dependablity. I'm posting the paper (in troff format) to comp.misc, so interested people can get it. If you can not get comp.misc, then please send me email, and I'll send it to you. I can also send a plain text version, for people who do not have nroff or troff. I'm also thinking about follow on work to compare data representation techniques (Sun's XDR vs. Apollo's RMR vs. Netwise's ASN.1). If you would like to help (especially if you use Apollo's NCS) please email me. Joshua Levy -------- Quote: "If you haven't ported your program, it's not Addresses: a portable program. No exceptions." joshua@atherton.com {decwrl|hpda|sun|pyramid}!athertn!joshua work:(408)734-9822 home:(415)968-3718 From apollo-request@umix.cc.umich.edu Tue Jul 18 17:44:31 1989 Date: 18 Jul 89 17:37:23 GMT From: braner@tcgould.tn.cornell.edu (Moshe Braner) Organization: Cornell Theory Center, Cornell University, Ithaca NY Subject: more Message-Id: <8441@batcomputer.tn.cornell.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu [] The Apollo "more" tool chooses it's own font, and takes a lot of time to start up. Quite annoying when, e.g., reading mail letter by letter (with PAGER=more). Is there an alternative? Has somebody written a simple "more" that does not do cursor addressing (and thus escapes the vt100 emulator)? Thanks. - Moshe PS: still would like a replacement for "vt100" too! From apollo-request@umix.cc.umich.edu Tue Jul 18 21:29:57 1989 Date: 18 Jul 89 20:50:54 GMT From: sahayman@iuvax.cs.indiana.edu (Steve Hayman) Organization: Computer Science Department, Indiana University Subject: What to do if node "F749" suddenly appears on your ring. Message-Id: <23487@iuvax.cs.indiana.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If someone offers you a really good deal on a diskless DN3000, with no monitor, and it happens to be node F749 - please let me know. It was stolen from one of our labs over the weekend. Exactly what use a diskless DN3000 will be to your average thief isn't clear to me. 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 Wed Jul 19 05:22:42 1989 Date: 17 Jul 89 14:11:40 GMT From: reilly%vtt%router%tut%draken%kth%mcvax.uucp@uunet.uu.net (Jim Reilly - reilly%vtttel@router.funet.fi) Organization: VTT/TEL Subject: problem using dbx Message-Id: <2748@tel2.tel.vtt.fi> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I'm trying to use 'dbx' on our Apollo 3500 (sr10.1) and am having some problems. I'm trying to use dbx from my vt220 terminal in my office, since I can't always be able to do debugging from the system console, as other people use the console quite a lot. I can't seem to get line #'s for my C code to appear at breakpoints or when single stepping. Instead, I get hex addresses and assembly language instructions. I tried a control experiment using just a small number of C source files and dbx seemed to work just fine. It only seems to be when I use dbx to run an executable compiled from a larger number (we have 40+ "C source files" in our system - some are small, others are relatively large) of object files, that I have problems. I've tried compiling with -g on every .c that goes into the executable and also tried compiling just the ones I care about with -g. Same thing, just hex addresses and assembly code. I'm just wondering if there is some sort of size limit for dbx on the Apollo, or some option flag I should try during compiling (I also tried -dba instead of -g for the heck of it). Has anyone else experienced this ? Found a work-around ? Any other suggestions ? Thanks! Jim Reilly, Please respond to: reilly%vtttel@router.funet.fi reilly%vtttel@FINFUN.BITNET From apollo-request@umix.cc.umich.edu Wed Jul 19 05:24:58 1989 Date: 17 Jul 89 16:56:53 GMT From: savela%vtt%router%tut%draken%kth%mcvax.uucp@uunet.uu.net (Markku Savela) Organization: Technical Research Centre of Finland Subject: cpp problem on sr10.1/sys5; single quotes within string? Message-Id: <2749@tel2.tel.vtt.fi> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We run into a strange problem when trying to compile some programs under Apollo SR10.1/sys5 combination (this does not seem to happen when running under bds4.3). The problem seems to center around single quotes (') within strings. Looking at the preprocessor output it seems that it adds those "line number hints" into incorrect places? The problem goes away, if single quotes are removed. The problem might be slightly difficult to replicate because of the "random" nature of those line-number lines... Me thinks we got a broken default "cpp" in use under SYS5 :) How do I force "cc" to use another and which one should I use? Or any other ideas about this? thanks, Markku Savela savela%vtttel@router.funet.fi ----------------- source fragment from "test.c" ---------------------- sprintf(line, "vtask='%s' state='%s' primitive='%s' blocks=%d bytes%lu\n", traceMemInfos[i].vtask->name, stateName, primName, traceMemInfos[i].blocks, traceMemInfos[i].used * sizeof(HEADER)); ----------------- output from cc -E test.c --------------------------- sprintf(line, "vtask='%s' state='%s' primitive='%s' blocks=%d # 1540 "test.c" bytes%lu\n", traceMemInfos[i].vtask->name, stateName, primName, traceMemInfos[i].blocks, traceMemInfos[i].used * sizeof(HEADER)); ----------------- sample of error message from cc -g -c test.c --- (1547) "vtask='%s' state='%s' primitive='%s' blocks=%d ******** Line 1547 of "test.c": [Error #003] Unterminated character string. (1548) bytes=%lu\n", ------------------end ---- From apollo-request@umix.cc.umich.edu Wed Jul 19 13:33:18 1989 id AA01004; Wed, 19 Jul 89 05:50:22 edt Date: Wed, 19 Jul 89 05:50:22 edt From: Royal B. Kellogg Message-Id: <8907190950.AA01004@ef8 .UMD.EDU> To: apollo@umix.cc.umich.edu Subject: More Regarding the use of more in the mailer, what about using the line editor, ed? The brouse command, b, bor b 20, say, gives a screenfull of message. I do not know if it can be used with mail. Bruce Kellogg Univ. of Maryland rbk@julia.umd.edu From apollo-request@umix.cc.umich.edu Wed Jul 19 13:38:39 1989 Message-Id: <8907191307.AA03786@umix.cc.umich.edu> Date: Wed, 19 Jul 89 16:56:23 SST From: fclim Subject: Re: More To: One ADU to another In article <8441@batcomputer.tn.cornell.edu> braner@tcgould.tn. cornell.edu (Moshe Braner) > The Apollo "more" tool chooses it's own font, and takes a lot > of time to start up. Quite annoying when, e.g., reading mail > letter by letter (with PAGER=more). Is there an alternative? > Has somebody written a simple "more" that does not do cursor > addressing (and thus escapes the vt100 emulator)? [digress] Darryl Conliffe and I were corresponding over this newgroup about a couple of weeks ago. Darryl started off by saying that most non-Aegis users invoke "more" or "cat" whenever they want to browse a file. [egress] There is a better method: use m3 (the right button on the mouse). Its definition is the same whether you use /sys/dm/std_keys or /sys/dm/unix_keys. Move the cursor onto any part of the filename and click the m3. The action taken by m3 is basically asking the DM (ie Display Manager) to invoke cv (Create a View) of the given file. A DM pad is created giving a porthole to the file. You can use the scroll keys (boxed arrow keys on the left of the keyboard) to scroll back and forth. [tis hard to get "more" to scroll back]. You can't setenv PAGE to cv because it's not a shell command. A workaround is to write a shell script: % cat > cv << BLAAAH #!/bin/sh /com/xdmc cv $1 BLAAAH % mv cv /bin # or your favorite binaries dir. % rehash % setenv PAGER cv "More" pulls the shell pad into a vt100 which uses the /sys/dm/fonts/vt100l font. So does vi. What I did was: % pushd /sys/dm/fonts % /com/chn vt100l -y # rename vt100l as vt100l.yy.mm.dd % ln -s vt100l.b vt100l % popd Now my vi is "brighter" because it is using a bold font. Hope this helps. fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. From apollo-request@umix.cc.umich.edu Wed Jul 19 19:31:38 1989 Date: 19 Jul 89 20:15:24 GMT From: sahayman@iuvax.cs.indiana.edu (Steve Hayman) Organization: Computer Science Department, Indiana University Subject: Re: What to do if node "F749" suddenly appears on your ring. Message-Id: <23526@iuvax.cs.indiana.edu> References: <23487@iuvax.cs.indiana.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >It was stolen from one of our labs over the weekend. False alarm - the thief must have realized that a diskless, screenless DN3000 wasn't going to do him/her much good, because the node showed up today in a washroom in another building on campus. I think we should just run the token ring into the washroom, rather than bringing the node back here ... Steve From apollo-request@umix.cc.umich.edu Wed Jul 19 21:36:44 1989 Date: 19 Jul 89 20:16:00 GMT From: flinn%apollo%ulowell%mailrus.uucp@tut.cis.ohio-state.edu (Donald Flinn) Organization: Apollo Computer, Chelmsford, MA Subject: Re: SR10.1 Installation Procedure ! Message-Id: <4484dd1d.8ecf@apollo.COM> References: <12735@well.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <12735@well.UUCP> rchrd@well.UUCP (Richard Friedman) writes: > >1. There needs to be a load/install option for the stand alone >system. In particular, there should be a clean-up procedure that >deletes unneeded parts of the software from the disk. Also, the >installation procedure could be smarter and not bother to load unneeded >system files. I have noticed that even tho only one SAU option is >selected, MINST loads all the SAU directories into the AA. Why? >Information about the parts of the system the user does not want >(such as /usr/games, /usr/new, domain_examples, unneeded manual pages, etc.) >should be requested at the start and skipped from the load process as well >as the install. > >2. Documentation of the load/install is terrible! The "Installing >Software" manual should have been re-issued with corrections rather than >having the corrections in the release notes. In the end, the messages that >come out of MINST and INSTALL++ during installation don't correspond to >anything in either document. This adds great anxiety when you are >2 hours into the installation and a question comes up that you don't know >how to answer. The documentation should be clearer on what happens when >you answer questions on the screen. All answers should be mentioned. > >3. Once the system is installed, there should be a backup procedure that >will transfer the system, with a boot record, to a backup medium, like >cartridge tape, so that should the disk have to be INVOL'd later on we >can re-load the system without having to go thru the whole load/install >procedure again! This seems simple enough to do. A system backup builder >can look around to see what is installed on the disk, prepare a >bootable tape in whatever structure it needs, and write the tape(s). >Later, after an INVOL, a RELOAD from the monitor shell should be able to >put everything back and setup for a boot back to DOMAIN_OS. Were this >system backup/reload available I could have saved at least 25 hours of >real agony! > >4. Finally, I have noticed that the load procedure at times will >retension a cartridge tape twice! Retensioning should be a y/n option >from the console and be global: "Should load volumes be retensioned >before being read [y/n]" If this is the second re-install today, I really >don't think I have to retension and would like to skip it. > >Lets hope SR10.2 looks better. And don't forget about us stand alone >sites, please! > >-- > ...Richard Friedman rchrd@well.uucp > (Pacific-Sierra Research/Berkeley, CA.) > also: {lll-crg,pacbell,hplabs}!well!rchrd Richard Thanks for your comments. We are trying to make RAI easy to use as well as give the flexibility that our different customer need or desire. This is an ungoing task. We welcome comments, suggestions and constructive criticism. As to your specific comments - 1. distaa is the program that handles loading the AA from media. It uses a script driver file which allows you to select parts of a product to load into the AA. You can generate one of these file using cfgsa (see the install manual on using cfgsa). cfgsa's output is a selection file and an override file. The selection file is the one that drives distaa. The override file restricts what you can pick during config and subsequent installs. This stops you from picking and/or trying to install a subproduct that you did not load into the AA (the overrides file and the selection files are paired.) In order to use cfgsa first rbak file 1 from the tape to get the release index for that product. Then run distaa using the selection file that you have generated. In this manner the AA will only contain those subproducts that you have choosen. ( The templates that we supply are built with cfgsa.) If you only choose one sau in the cfgsa session, only one sau will be loaded into the AA. Likewise, if you don't choose /usr/games you will not get /usr/games in the AA. 2. Documentation is being rewritten. 3. Save your selection and override files to a tape. Next boot from your boot tape to get your node up and running with the boot software. Restore the selection and override files. Run distaa with the restored selection file and the -l switch. This is equivalent to a reload. 4. We are following the cartridge tape manufactuer rules which say that you must retension the tape each time you use it. From apollo-request@umix.cc.umich.edu Thu Jul 20 05:35:40 1989 Date: 20 Jul 89 01:23:35 GMT From: tim%merlin%bruce%munnari.oz.au%uhccux.uucp@ames.arc.nasa.gov (Tim Monks) Organization: none Subject: cc (stack vs heap) query and another on f77 Message-Id: <950@merlin.bhpmrl.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am trying to port some C and Fortran programs from Silicon Graphics (running Irix 3.1 ~ Sys V + enhancements) to a DN10000 under SR10.1 (BSD) and have come up with two basic problems : (i) C Consider the following C segment : #include main() { double x[1000]; x[0] = 1.00; x[999] = -1.0; fprintf(stdout,"%lf, %lf \n",x[0], x[999]); fprintf(stdout,"OK. \n"); fflush(stdout); } x is put onto the stack, so as I increase the size of this array I will get a run time error : Warning #123 Function needs ... bytes of stack which exceeds maximum stack size of 524224. I've been told that to get the array put on the heap I can either declare it as global or use malloc. I don't want to do either (mainly because the SG version doesn't need it) but also I don't want to mess around with 1D pointers when doing lots of indexing of large 2D arrays (yes I am new to C) Are there any other ways of getting around the problem ? (ii) Fortran Again a piece of code : parameter (N=1000) real*8 x(N) x(1) = 1.00 x(N) = N write(6,*) x(1), x(N) write(6,*) 'OK' end The size of the fortran binary is proportional to N !!! N Image size 1000 32 273 10000 104 305 100000 824 305 1000000 8 024 305 10000000 80 024 305 (bytes) 100000000 compiler failed What gives ? - what am I doing wrong ? -- Dr. Tim Monks Image Processing & Data Analysis Group | (direct) +61-3-566-7448 BHP Melbourne Research Laboratories | (switch) +61-3-560-7066 245 Wellington Rd, Mulgrave, 3170, | (fax) +61-3-561-6709 AUSTRALIA | (EMAIL) tim@merlin.bhpmrl.oz From apollo-request@umix.cc.umich.edu Thu Jul 20 11:12:05 1989 Date: 17 Jul 89 02:42:28 GMT From: rodneyc%spinifex%elecvax%usage%basser%metro%otc%munnari.oz.au%uhccux.uucp@ames.arc.nasa.gov (Rodney Campbell) Organization: EE & CS, Uni N.S.W., Sydney, Australia Subject: GPR filled inverted circle BUG Message-Id: <406@spinifex.eecs.unsw.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Has anyone noticed a BUG in the GPR routines for drawing a filled inverted circle. The routines work for rectangles, lines, etc but do not work for circles. The filled circles are drawn in the last drawing mode.. ie foreground or background colour but not inverted. (see the example program in /domain_examples/dialog/draw.... If anyone has any idea about this or a possible fix could they please post it or mail me. I am writing a painting program on the apollo workstations for my undergraduate thesis. Thanks in advance, Rodney.. _____ Rodney Campbell :: University of New South Wales / / ACSnet,CSNET: rodneyc@spectrum.eecs.unsw.oz / / / UUCP: {uunet,mcvax}!spectrum.eecs.unsw.oz!rodneyc /__/ ___ ___/ //\ Snail: 9 Irvine Street, Kingsford, 2032. / | / / / / //__\ N.S.W. Australia. / |_/__/_/__/ \X/ \MIGA Phone: +61 02 344 6975 From apollo-request@umix.cc.umich.edu Thu Jul 20 16:08:26 1989 Date: 20 Jul 89 15:59:44 GMT From: kts%quintro%tiamat.uucp@uunet.uu.net (Kenneth T. Smelcer) Organization: none Subject: Re: More Message-Id: <1989Jul20.155944.23435@quintro.uucp> References: <8907191307.AA03786@umix.cc.umich.edu>, <1989Jul20.145401.23083@quintro.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1989Jul20.145401.23083@quintro.uucp> kts@quintro.UUCP (Kenneth T. Smelcer) writes: >In response to the original problem, the small font size isn't due to >invoking the vt100, but because it isn't! When you invoke 'more' with >a filename, it start the emulator and everything works fine. When 'more' >reads from stdin, it doesn't start a vt100 window; it switches to a >tiny font and displays to the output pad. I assume this is because >the 'curses' package sees that input is not from the terminal, so it >doesn't start the emulator (is this how curses/vt100 works?). I'm don't >have any ideas how to fix this (except by using a mailer like 'elm' :-) >Anybody else have a suggestion? > Its been pointed out to me that I wasn't very clear about this. Here are some examples: (BTW, the font behavior only happens at 10.1) 1. /usr/ucb/more textfile (start vt100 emulator with vt100 font; normal operation) 2. cat textfile | /usr/ucb/more (keep normal pad, switch to small font, display text in output area) We tried this at 9.7 and it works the same, except that it uses the normal font. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ken Smelcer Quintron Corp. quintro!kts@lll-winken Quincy, IL tiamat!quintro!kts@uunet From apollo-request@umix.cc.umich.edu Thu Jul 20 18:11:59 1989 Date: 20 Jul 89 17:02:06 GMT From: kcantrel%digi.uucp@uunet.uu.net (Keith Cantrell) Organization: DSC Communications, Plano Tx. Subject: Problems with remote logins. Message-Id: <187@digi.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am having a weird problem with remote machines logging into my Apollo DN3500 running BSD4.3. If the remote machine is using anything else but HoneyDanBer uucp to login, they will not get past the "Password:" prompt. The problem seems to be that after the remote machine sees "login:" prompt they send their account name, next they see "Password:" and then they send their password but nothing happens. And if I look at the output from "ps -ax" command I see that getty has passed execution to "login -p username" but it is not getting any CPU time. It seems as though the "login" program is not seeing the password being sent by the remote machine. The weird part is that if the user at the remote host uses tip (or some kind of communication program) and does the login sequence by hand, it all seems to work. Now I have noticed that if I try in login to this Apollo by hand and am talking to it at 7 data bits and no parity, I will get the same results, but the remote machine that is trying to call us swears that his is using 8 data bits, no parity, and 1 stop bit. Has anybody else seen this problem??? And more importantly, does anybody have a solution?? Thank you for any help, Keith ----------------------------------------------------------------------- Keith Cantrell Phones: hm: 214-492-1088 Apollo Computer wk: 214-519-2399 @ DSC A Subsidiary of Hewlett-Packard USMAIL: EMAIL: 2100 Sonata Ln cantrell@attctc.DALLAS.TX.US Carrollton TX 75007 or ...!uunet!digi!kcantrel ----------------------------------------------------------------------- From apollo-request@umix.cc.umich.edu Thu Jul 20 18:34:41 1989 Date: 20 Jul 89 14:54:01 GMT From: kts%quintro%tiamat.uucp@uunet.uu.net (Kenneth T. Smelcer) Organization: none Subject: Re: More Message-Id: <1989Jul20.145401.23083@quintro.uucp> References: <8907191307.AA03786@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8907191307.AA03786@umix.cc.umich.edu> GBOPOLY1@NUSVM.BITNET (fclim) writes: >In article <8441@batcomputer.tn.cornell.edu> braner@tcgould.tn. > cornell.edu (Moshe Braner) > >> The Apollo "more" tool chooses it's own font, and takes a lot >> of time to start up. Quite annoying when, e.g., reading mail >> letter by letter (with PAGER=more). Is there an alternative? >> Has somebody written a simple "more" that does not do cursor >> addressing (and thus escapes the vt100 emulator)? > >[digress] >Darryl Conliffe and I were corresponding over this newgroup about >a couple of weeks ago. Darryl started off by saying that most >non-Aegis users invoke "more" or "cat" whenever they want to >browse a file. >[egress] > [ description of cv with the m3 button ] > >You can't setenv PAGE to cv because it's not a shell command. >A workaround is to write a shell script: > % cat > cv << BLAAAH > #!/bin/sh > /com/xdmc cv $1 > BLAAAH > % mv cv /bin # or your favorite binaries dir. > % rehash > % setenv PAGER cv > >fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu I don't think this will work because mail sends the text to more via stdin, not by filename. You could get this to work by creating a temp file and using DM with it, but that seems silly. Is there a way to get a pad to take data from stdin instead of a file? BTW, if you want a pager that lets you move around in the file, there is a program in the comp.sources.unix archives called 'less' that works similarly to more, but gives you full cursor movement (ala vi) and has quite a few nice features. In response to the original problem, the small font size isn't due to invoking the vt100, but because it isn't! When you invoke 'more' with a filename, it start the emulator and everything works fine. When 'more' reads from stdin, it doesn't start a vt100 window; it switches to a tiny font and displays to the output pad. I assume this is because the 'curses' package sees that input is not from the terminal, so it doesn't start the emulator (is this how curses/vt100 works?). I'm don't have any ideas how to fix this (except by using a mailer like 'elm' :-) Anybody else have a suggestion? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ken Smelcer Quintron Corp. quintro!kts@lll-winken Quincy, IL tiamat!quintro!kts@uunet From apollo-request@umix.cc.umich.edu Thu Jul 20 20:15:21 1989 Date: 19 Jul 89 14:54:23 GMT From: rpjday%ccu%alberta%ncc%pyramid%voder.uucp@ucbvax.Berkeley.EDU (rpjday) Organization: University of Manitoba, Winnipeg, Manitoba, Canada Subject: sockets bug in 10.1 Message-Id: <231@ccu.UManitoba.CA> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Being a bit of a rookie, both in terms of the Apollo and this newsgroup, chances are this issue has come up before. There appears to be a rather serious bug in our DN3000 regarding sockets in BSD. A set of application programs communicating via sockets run merrily along for awhile, then just lock up. A trace facility shows that a pair of processes has deadlocked, with the process A send-blocked on process B, and B receive-blocked on process A. I have since learned that we are not the only Apollo site to have experienced this bit of nastiness. Is this a recognized bug? Is there a fix? Enquiring minds want to know. Rob P. J. Day rpjday@ccu.umanitoba.ca From apollo-request@umix.cc.umich.edu Thu Jul 20 20:23:27 1989 Date: 20 Jul 89 18:49:44 GMT From: dennis%peanuts.nosc.mil.uucp@nosc.mil (Dennis Cottel) Subject: Re: More Message-Id: <1377@nosc.NOSC.MIL> References: <8907191307.AA03786@umix.cc.umich.edu>, <1989Jul20.145401.23083@quintro.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu kts@quintro.uucp (Kenneth T. Smelcer) writes: > I don't think this will work because mail sends the text to more via > stdin, not by filename. You could get this to work by creating a temp > file and using DM with it, but that seems silly. Is there a way to > get a pad to take data from stdin instead of a file? We use the Berkeley Mail program which, at least at SR9.7, has the file name '/usr/ucb/more' wired in. I patched the binary to change the name to the relative pathname 'more.pager' and then put a link from more.pager to /com/crpad in our local bin directory. Now each user gets a Display Manager pad by default, but can set a personal pager if desired. Ugly but it works. 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 Thu Jul 20 21:46:42 1989 Date: 20 Jul 89 16:22:51 GMT From: reb%quintro%tiamat.uucp@uunet.uu.net (Roger E. Benz) Organization: none Subject: Third party catalogue Message-Id: <1989Jul20.162251.24028@quintro.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The long awaited catalogue is here! I just received a copy from my salesman. Its called 'Apollo Partners Applications Catalogue' and is 1142 pages long. It covers 1092 software and hardware products and services from over 450 vendors in 24 applications areas. -- 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 Jul 21 10:13:15 1989 Date: 21 Jul 89 06:48:42 GMT From: davew%gvgpsa%tektronix%zephyr.ens.tek.com.uucp@uunet.uu.net (David C. White) Organization: Grass Valley Group, Grass Valley, CA Subject: Re: Problems with remote logins. Message-Id: <1220@gvgpsa.GVG.TEK.COM> References: <187@digi.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <187@digi.UUCP> kcantrel@digi.UUCP (Keith Cantrell) writes: >I am having a weird problem with remote machines logging into my Apollo DN3500 >running BSD4.3. If the remote machine is using anything else but HoneyDanBer >uucp to login, they will not get past the "Password:" prompt. The problem >seems to be that after the remote machine sees "login:" prompt they send their >account name, next they see "Password:" and then they send their password but >nothing happens. And if I look at the output from "ps -ax" command I see that >getty has passed execution to "login -p username" but it is not getting any >CPU time. It seems as though the "login" program is not seeing the password >being sent by the remote machine. The weird part is that if the user at the >remote host uses tip (or some kind of communication program) and does the >login sequence by hand, it all seems to work. Now I have noticed that if I >try in login to this Apollo by hand and am talking to it at 7 data bits and no >parity, I will get the same results, but the remote machine that is trying to >call us swears that his is using 8 data bits, no parity, and 1 stop bit. > >Has anybody else seen this problem??? And more importantly, does anybody have >a solution?? I have encountered this problem calling into SYS5 type systems from an Ultrix system. There were really two problems. The first was the parity which was easily fixed by the following sequence before expecting the login: prompt - "" P_ZERO "" \d\d The second problem involved the called system apparently not seeing the password even though my system saw and responded to both the 'login' and 'password' prompts. I'm not sure exactly where the password got lost but the system I was calling never seemed to see it even though I sent it. I could get past it by 'echo password > /dev/ttyd2' and I would get the login prompt again. I could then use the 'echo' command and send the login and password manually and the connection would start up normally. It appeared that the receiving system was not seeing all of the password since it would give me a bad login message and start over again. The solution that fixed this problem was to put a couple of delays after sending the response to the login prompt as follows: ogin:-\r-ogin:-\r-ogin: response\d\d ssword:--ssword:--ssword: xxxxx This seemed to correct the problem. If anybody knows why this works I would be very interested in hearing about it. -- David White Grass Valley Group, Inc. VOICE: +1 916.478.3052 P.O. Box 1114 Grass Valley, CA 95945 FAX: +1 916.478.3778 Internet: davew@gvgpsa.gvg.tek.com UUCP: ...!tektronix!gvgpsa!davew From apollo-request@umix.cc.umich.edu Fri Jul 21 10:13:24 1989 Date: 20 Jul 89 04:00:00 GMT From: oliveria%caen.engin.umich.edu%mailrus.uucp@tut.cis.ohio-state.edu (ROQUE DONIZETE DE OLIVEIRA) Organization: U of M Engineering, Ann Arbor, Mich. Subject: tn3270 Message-Id: <448a5f5d.c19b@settle.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Has anyone ported version 4.1.1 of tn3270 on apollos under sr10.1/BSD4.3 ? If so, could you send me the diffs or let me know where I can get it ? I'm specially having problems with the keyboard mapping file map3270. Any help will be appreciated. Roque D. Oliveira oliveria@caen.engin.umich.edu From apollo-request@umix.cc.umich.edu Fri Jul 21 14:15:16 1989 Message-Id: <8907211449.AA05942@umix.cc.umich.edu> Date: Fri, 21 Jul 89 10:45 EDT From: FERGUSON%TMASL.EXXON.COM@CUNYVM.CUNY.EDU Subject: Ethernet throughput To: apollo@umix.cc.umich.edu X-Vms-To: APOLLO Why is it that typical FTP data rates are only in the area of 50 kbytes/sec? I've got an ethernet link between a DN4000 and another machine, no other hosts on the wire. I figured I'd have to be getting few to no collisions, and that my throughput would be great. Wrong. I'm using thin wire...would I gaining much by going to thick? Is FTP just a crappy way to move files? Would NFS give me significantly better throughput? I know about the better transparency, but how's the performance? I see variations in data rate (on the comments made by FTP) from 30 kbytes/sec to 90 kbytes/sec, which seems kind of flaky to me. Does FTP create its own collisions? This brings up another point. I've heard lots of salespeople talking about 100 Mbit/sec Ethernet, and FDDI fiber optic 100 Mbit/sec network support coming up. When can we users expect actual products? Thanks to all, Scott Ferguson ferguson@erevax.bitnet Exxon Research & Engineering Annandale, NJ 08801 (201) 730-2339 From apollo-request@umix.cc.umich.edu Fri Jul 21 14:29:46 1989 Date: 21 Jul 89 13:02:00 GMT From: bergstr%hi-csc.uucp@uunet.uu.net (Darryl Bergstrom) Organization: csdd Subject: Re: more Message-Id: <448d680c.12c4f@hi-csc.UUCP> References: <8441@batcomputer.tn.cornell.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8441@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu (Moshe Braner) writes: >The Apollo "more" tool chooses it's own font, and takes a lot >of time to start up. Quite annoying when, e.g., reading mail >letter by letter (with PAGER=more). Is there an alternative? >Has somebody written a simple "more" that does not do cursor >addressing (and thus escapes the vt100 emulator)? >Thanks. >- Moshe > Put something like this in your .login/.cshrc (take your pick) switch (`tty`) case '/dev/tty': case '/dev/display': echo "Terminal type is: $TERM" setenv EDITOR ~/com/dm_editor setenv VISUAL ~/com/dm_editor setenv PAGER /com/crpad breaksw default: set term=unknown source ~/com/termset setenv EDITOR /usr/ucb/vi setenv PAGER ~/com/less stty erase kill ^U intr ^C quit ^] start ^Q stop ^S eof ^D \ susp ^Z rprnt ^R flush ^O werase ^W lnext ^V crtkill crterase -nohang endsw and here is the script dm_editor #!/com/sh # This is a shell hook into the apollo display manager editor. # Author R. Cloutier -- Aug 8 1986 # Darryl Bergstrom -- June 10 1989 # # This aegis shell script will open a dm editor window to the file that # is passed as the first argument to this script. # # change the line below if you want to run on SR9 display ==> tty IF eqs ((^"/usr/bin/tty")) "/dev/display" THEN # uncomment this line if you want to have caps mapped to :x in SR9 # xdmc ce ((^"args ^1 | /bin/sed -e 's/[A-Z]/:&/g'")) xdmc ce ^1 IF eqs ^1 THEN args "You must supply a filename:" "^0 filename" ELSE # readc -p "Hit the return key AFTER you have saved the file: ^1" ans while llkob | fpat ^1 > /dev/null do enddo ENDIF ELSE args "Cannot use a display manager edit window, using ex, instead." /bin/ex ^1 ENDIF This works here at hi-csc and should elsewhere. Much faster you get to use the DM editor. -- -Darryl Bergstrom -Honeywell Sensor & System Development Center, Golden Valley, Mn -UUCP: uunet!hi-csc!bergstr -ARPA: bergstr@hi-csc.honeywell.com || darryl@ux.acss.umn.edu From apollo-request@umix.cc.umich.edu Fri Jul 21 15:39:20 1989 Date: 18 Jul 89 19:07:18 GMT From: majka%moose.cs.ubc.ca%ubc-cs.uucp@beaver.cs.washington.edu (Marc Majka) Organization: UBC Department of Computer Science, Vancouver, B.C., Canada Subject: C Math on DN10000 Message-Id: <2512@ubc-cs.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Help! I recently upgraded our DN10000 from 10.0 to 10.1, and all the C math functions have disappeared. For example: main() { float x, sin(); x = sin(1.0); } when compiled, gives the message: % cc foo.c undefined first referenced symbol in file matherr /usr/lib/crt0.o sin foo.o ld warning: Output file a.out not executable The "matherr" object also appears in a console message when I reboot the node. I get something like: Loading Init. Undefined Global "ldexp" referenced in /lib/libc Undefined Global "ldexp" referenced in /lib/libc Undefined Global "matherr" referenced in /lib/libc I've called the hotline about this. The languages group eventually gave up and declared that it was a system problem. The system group has no idea what is going on. I can't believe that this is happening on every DN10000 which is running SR10.1.p! The library files /lib/syslib and /lib/clib are there, but something must be missing. Any help would be greatly appreciated! --- Marc Majka - System Manager UBC Computer Science From apollo-request@umix.cc.umich.edu Fri Jul 21 21:33:49 1989 Date: 21 Jul 89 19:09:15 GMT From: lcz%dptudg%dpmizar%swrinde%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Lee Ziegenhals) Organization: Datapoint Corporation, San Antonio, TX Subject: Re: Problems with remote logins. Message-Id: <269@dptudg.sat.datapoint.com> References: <187@digi.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu kcantrel@digi.UUCP (Keith Cantrell) writes: >I am having a weird problem with remote machines logging into my Apollo DN3500 >running BSD4.3... > ...the remote machine that is trying to >call us swears that his is using 8 data bits, no parity, and 1 stop bit. I have had this problem several times when calling *out* from my 4.3 system, and it was a parity problem every time. I solved the problem by "sending" a P_ZERO from my L.sys entry for those systems to force the 8th bit to zero. If the remote system administration swears that they are using the correct parity, etc., then that may not be the problem. However, I would double- check; that's what it sound like to me! -Lee From apollo-request@umix.cc.umich.edu Sat Jul 22 03:24:03 1989 Message-Id: <8907220354.AA23919@umix.cc.umich.edu> Date: Sat, 22 Jul 89 11:37:40 SST From: fclim Subject: What are /dev/padnn and /dev/crpadnn in SR10? To: One ADU to another What are they? What are they for? What do they do? How do they work? Is the number of /dev/padnn equal to the number listed in /sys/help/limits.hlp? (ie `ls /dev/pad* | wc -w` == `awk -e '$1 == "pads" { print $NF; exit }' /sys/help/limits.hlp`) Many thanks in advance. fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. From apollo-request@umix.cc.umich.edu Sat Jul 22 05:23:14 1989 Date: 21 Jul 89 16:47:28 GMT From: rchrd%well.uucp@apple.com (Richard Friedman) Organization: RCHRD 2855 Telegraph #415 Berkeley CA 94705 Subject: Re: SR10.1 Installation Procedure ! Message-Id: <12805@well.UUCP> References: <12735@well.UUCP>, <4484dd1d.8ecf@apollo.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Its quite obvious that the team at apollo that put together the installation tools did not actually attempt to do an OS install of 10.1 on a stand alone node. I think the documentation is an educated guess by the writers as to what should work. For a stand alone node, there is really no reason whey load and install should be different phases of the process. There should be a MINST question: Is this a stand-alone node? A yes response gets you into a combined load/install dialog that lets you specify what parts of the system you want, etc. and does the load directly into the system rather than creating an /install area and then creating redundant links to it to create the real system. The poor user, who has little time to completely understand the implications of the install procedure (which is not documented to begin with) suffers the anxiety of not knowing the complete ramifications of all the install options. We rely on apollo providing simple canned routines like MINST and INSTALL. THe stand-alone system does not have a partner node to suck off critical files. Once a stand alone disk is INVOL'd there is nothing but the system installation boot tape. This tape has nothing real on it and is to be used only to load in the system. It doesnt even have a complete set of diagnostics in the sysboot record, so once you do an invol you cant do a disk test or cpu tes (win.dex or cpu.dex) until AFTER you have successfully installed the system (which takes 3 hours!). There are other problems, like what to do when there is some sort of failure during the install process... how can you reliably recover or restart without having to go all the way back to invol the disk! I am talking about OS installations, not optional products... There should be a simple procedure, as I mentioned earlier, for saving the system, not just a simple way to reinstall from the install media. I want to backup the system on my own tapes, preserving my own customizations, invol the disk, and reload in a simple way that requires minimal operator interventions. Why cant I do this?? Apollo needs to work more on the installation process. In the meantime, I'd like to find out how many stand alone nodes are out there and what their experiences are regarding sr10 installs. For that, watch this space. -- ...Richard Friedman rchrd@well.uucp (Pacific-Sierra Research/Berkeley, CA.) also: {lll-crg,pacbell,hplabs}!well!rchrd From apollo-request@umix.cc.umich.edu Sat Jul 22 07:36:41 1989 Date: 22 Jul 89 06:18:31 GMT From: micky%cunixc.uucp@columbia.edu (Micky Liu) Organization: Columbia University Subject: Possible to mount others disks onto DN10000? Message-Id: <1709@cunixc.cc.columbia.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am rather new to these Apollo's, but have been managing Sun's for quite some time now... Is it possible to mount NFS disks onto the DN10000. I have looked in the man pages and see that it is possible to remote mount the DN10000 disks, but I want to mount the disks from my Convex C210 onto my Apollo. After looking around I've found /etc/nfsd, but no corresponding /etc/biod. Is Apollo's offering of NFS only a one way deal? Thanx! Micky arpa: micky@cunixc.cc.columbia.edu uucp: ...!rutgers!columbia!cunixc!micky bitnet: malua@cuvmc From apollo-request@umix.cc.umich.edu Sat Jul 22 07:41:54 1989 Date: 21 Jul 89 21:05:22 GMT From: davidb%inmos.co.uk%inmos%ukc%mcvax.uucp@uunet.uu.net (David Boreham) Organization: none Subject: In praise of SR10.1 Message-Id: <1705@brwa.inmos.co.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu O.K, this is probably old hat to most of you but I've just in- stalled (or had installed -:) SR10.1 and X(apollo)11 on an unused DN3000 with 4meg and 140meg disk (we are a mentor site and have not got the SR10.1 mentor stuff yet, so the nodes used for CAD work can not be SR10'ed). SR10.1 is *so* much better than 9.7/domain/IX, I can't believe it. I don't care what people say about the memory and disk usage -- My old 3000 goes much faster than it did before and runs all the daemons you ever need in 4 meg! Also, after spending months hacking real UNIX code so'ws it'd compile on the Apollo, I have just finished porting the NNTP re- mote news system in three hours. It only needed one hack and that was to remove an error in the code ! I've got the DNS resolver system so I don't have to keep copying /etc/hosts from a SUN. I've got an (apparently) very good X11 port, with "mwm", the motif window manager, which is really pretty. All this and machines which can be administered by one person, while he does a real job as well ! 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 Jul 22 15:27:53 1989 Date: Fri, 21 Jul 89 15:59:36 edt From: cordery@love.MIT.EDU (Matthew Cordery) Message-Id: <8907211959.AA07699@gilbert.mit.edu> To: apollo@umix.cc.umich.edu Subject: 2DGMR character drawing... I am writing some specialized graphics programs and I find myself constantly running into the problem of 2DGMR's abysmally poor text drawing capabilities. You know, things like scaling, justification, super/subscripting, it actually doing what you think you are telling it. I am wondering if anyone out there has any C subroutines that might handle such things? Matthew J. Cordery cordery@gilbert.mit.edu "The strong do what they will, the weak do what they must." Thucydides address unknown From apollo-request@umix.cc.umich.edu Sat Jul 22 15:34:47 1989 Date: Sat, 22 Jul 89 13:28:50 CDT From: Andrew M. Wescott Message-Id: <8907221828.AA02651@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu, micky%cunixc.uucp@umix.cc.umich.edu Subject: Domain NFS Domain NFS is definitely a two-way street. Rather than /etc/biod, you need to run /etc/mountd, /etc/nfsd, and /etc/portmap. I suggest you look at: Using NFS on the Domain Network (0104140A00). As far as remote mounts from the dn10000 go, you really don't need to run any demons. We have run mounts in both directions between a Sequent Symmetry and a dn10000 with no problems. Andrew Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Sat Jul 22 15:34:49 1989 Date: Sat, 22 Jul 89 13:23:20 CDT From: Andrew M. Wescott Message-Id: <8907221823.AA02638@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu, micky%cunixc.uucp@columbia.edu Subject: Re: Possible to mount others disks onto DN10000? Domain NFS is definitely a two-way street. Rather than /etc/biod, you need to run /etc/mountd, /etc/nfsd, and /etc/portmap. I suggest you look at: Using NFS on the Domain Network (0104140A00). As far as remote mounts from the dn10000 go, you really don't need to run any demons. We have run mounts in both directions between a Sequent Symmetry and a dn10000 with no problems. Andrew Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Sun Jul 23 07:30:29 1989 Date: 22 Jul 89 13:48:07 GMT From: achille%cernvax%mcvax.uucp@uunet.uu.net (achille petrilli) Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Subject: Re: more Message-Id: <1039@cernvax.UUCP> References: <8441@batcomputer.tn.cornell.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8441@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu (Moshe Braner) writes: >[] > >The Apollo "more" tool chooses it's own font, and takes a lot >of time to start up. Quite annoying when, e.g., reading mail >letter by letter (with PAGER=more). Is there an alternative? Hi, I defined PAGER to be a small program that opens an edit pad in read-only mode. This way I get a new window for each message and I can keep it around as long as I want. Another possibility is to use /com/crpad as a pager, but it's slower than opening an edit pad. If there is interest for such a program, I could post it. Keep in mind that it's running under sr10. Hope this helps, Achille Petrilli Cray and PWS operations From apollo-request@umix.cc.umich.edu Mon Jul 24 01:29:38 1989 Message-Id: <8907240327.AA14883@umix.cc.umich.edu> Date: Mon, 24 Jul 89 09:44:41 SST From: fclim Subject: Re: more To: One ADU to another I like to thank Deborah Swanberg for sending me the following note which I am resending to netland for the perusal of others. --------------------Original Message------------------------------------ From: Deborah Swanberg To: GBOPOLY1%NUSVM.BITNET@CUNYVM.CUNY.EDU, , Date: 21 Jul 1989 10:41 EDT Subject: Re: More From: fclim <@CUNYVM.CUNY.EDU:GBOPOLY1@NUSVM.BITNET> To: One ADU to another Date: Wed, 19 Jul 89 16:56:23 SST Subject: Re: More "More" pulls the shell pad into a vt100 which uses the /sys/dm/fonts/vt100l font. So does vi. What I did was: % pushd /sys/dm/fonts % /com/chn vt100l -y # rename vt100l as vt100l.yy.mm.dd % ln -s vt100l.b vt100l % popd Now my vi is "brighter" because it is using a bold font. This requires administrative control. Individual users can have control over their own vi fonts. To give credit, here's a message from long long ago. From: bts%sas%rti.uucp@mcnc.org To: umix.cc.umich.edu!apollo Date: 31 Jul 88 05:58:19 GMT Organization: SAS Institute Inc, Cary NC Subject: Re: Reprogramming the function keys on the vt100 emulator ...If a local font is available with the name vt100s, vt100 will use that rather then then one in /sys/dm/fonts. With the way vt100 works in sr9.7, if you start up one vt100 session and then end it, the next session will use the same font as the previous (now ended) session, unless you sigp the vt100_server. (This was done so that later vt100's fire up super-fast.) That way, you can start up later vt100's in any directory you want, so long as you earlier fired up one in a directory with the "vt100s" font you want. ... {stuff deleted} (I might note parenthetically at this point that I am a user rather than an administrator. I believe I'm a fairly knowledgable user, but I lack the [moral if not technical] authority to change /sys/dm/fonts anyway.) --Brian, __________________________________________________ the man from |Brian T. Schellenberger ...!mcnc!rti!sas!bts Babble-On |104 Willoughby Lane work: (919) 467-8000 x7783 ____________________________|Cary, NC 27513 home: (919) 469-9389 Deborah Swanberg Center for Information Technology Integration (CITI) University of Michigan 2901 Hubbard Ann Arbor, MI 48105 313-998-7479 deborah@citi.umich.edu --------------------End of Original Message------------------------------ fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. From apollo-request@umix.cc.umich.edu Mon Jul 24 03:25:27 1989 Message-Id: <8907240320.AA14713@umix.cc.umich.edu> Date: Mon, 24 Jul 89 09:57:03 SST From: fclim Subject: What are /dev/padnn and /dev/crpnn in SR10? (Was: ... /dev/crpadnn ...) To: One ADU to another Last week, I send out some questions on /dev/padnn and /dev/crpnn. Please note that my "Subject:" field contained a mistake. Anyway, here are some more questions: Will the OS use a /dev/pad when a user invokes the DM ce or cv command; or invokes /com/crpad; or invokes a program that calls pad_$create_window() ? Will one have job control if one invokes "/com/crp /bin/csh -on ..." ? [At SR9.7, there is no job control in a remote csh via /com/crp] Many thanks in advance. fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. From apollo-request@umix.cc.umich.edu Mon Jul 24 11:41:08 1989 Message-Id: <8907241157.AA01868@umix.cc.umich.edu> Date: 24 Jul 89 06:36:00 CST From: "DAVE ERSTAD" Subject: Re: C Math on DN10000 To: "apollo" > all the C math functions have disappeared. For what it's worth, we don't have this problem - your sample program compiled and ran fine. We are running 10.1.P. The missing globals are all in syslib, not clib. You might do a "bind /lib/syslib -glob" and see what's there. (Note that is an Aegis /com/bind, not a Unix bind). Dave Erstad Principal Design Automation Engineer Honeywell SSEC From apollo-request@umix.cc.umich.edu Mon Jul 24 11:41:15 1989 Date: 24 Jul 89 11:54:50 GMT From: feigin@tcgould.tn.cornell.edu (Unix Engihacker) Organization: Cornell Theory Center, Cornell University, Ithaca NY Subject: Signature/Addresses for previous posting -- Sorry ! Message-Id: <8479@batcomputer.tn.cornell.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Pnews forgot to include my .sig, which has my addresses....... AWF -- Internet: feigin@tcgould.tn.cornell.edu Adam Feigin Bitnet: feigin@crnlthry Workstation Consultant {backbonz}!cornell!batcomputer!feigin Cornell National Supercomputer Facility Workstation Technologies Group From apollo-request@umix.cc.umich.edu Mon Jul 24 11:49:22 1989 Date: 24 Jul 89 11:51:57 GMT From: feigin@tcgould.tn.cornell.edu (Unix Engihacker) Organization: Cornell Theory Center, Cornell University, Ithaca NY Subject: Call for Papers -- ADUS Unix SIG Message-Id: <8478@batcomputer.tn.cornell.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The ADUS Unix Special Interest Group will be having a session (maybe more than one, depending on the number of papers submitted) at the Annual ADUS Conference in New Orleans in September. We are soliciting papers from ADUS members (old hands or new !) for our session(s). Unix is a rapidly growing (changing ??) way of life for all workstation users, and almost any topic relating to Unix would be appropriate for our session. Of special interest would be papers describing/reporting on the latest developments at the Open Software Foundation, how you've taken advantage of the Unix functionality at SR10 (and beyond), and the integration of Apollo equipment in the generic Unix environment. If you are interested in presenting a paper at the conference, please send an abstract to myself or Andrea Woloski (woloski_a@apollo.com). My addresses are below. AWF From apollo-request@umix.cc.umich.edu Mon Jul 24 11:54:54 1989 Date: 23 Jul 89 21:39:26 GMT From: levin%magnus%srhqla%csun%usc%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Michael M Levin) Organization: Silent Radio, Los Angeles Subject: Re: Problems with remote logins. Message-Id: <590@magnus.SR.COM> References: <187@digi.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <187@digi.UUCP> kcantrel@digi.UUCP (Keith Cantrell) writes: >I am having a weird problem with remote machines logging into my Apollo DN3500 >running BSD4.3. If the remote machine is using anything else but HoneyDanBer >uucp to login, they will not get past the "Password:" prompt. The problem >..... Both the problem and the solution to it are NOT unique to Apollo, although it does appear to be related to non-HDB systems calling into a BSD environment, but none of that matters. If you simply have the calling party add a \n to the end of the password in their L.sys file, that will fix the problem. It would appear that without it being there, it doesn't do a NEWLINE at all, and therefore just hangs. In other words, if the chat script is doing something like: ..... in:--in: foo word: bar just change it to be ..... in:--in: foo word: bar\n And ALL WILL START WORKING miraculously. Or else I'm wrong. Please drop me a note via email and let me know if it cures the problem for you, or if I'm off-base. Good Luck, Mike Levin -- _ _ | | ___ ___ |_| ___ Michael Levin SilentRadio Headquarters- Los Angeles | |/ ._\| | || || \ 20732 Lassen Street, Chatsworth CA 91311 U.S.A. |_|\___/ \_/ |_||_|_| INTERNET:levin@SR.COM or {att|csun|srhqla}!magnus!levin From apollo-request@umix.cc.umich.edu Mon Jul 24 13:26:05 1989 Date: 24 Jul 89 14:23:00 GMT From: pcc%apollo.uucp@eddie.mit.edu (Peter Craine) Organization: Apollo Computer, Chelmsford, MA Subject: Re: C Math on DN10000 Message-Id: <449cc6f0.20291@apollo.COM> References: <2512@ubc-cs.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <2512@ubc-cs.UUCP> majka@cs.ubc.ca (Marc Majka) writes: > >The "matherr" object also appears in a console message >when I reboot the node. I get something like: > > Loading Init. > Undefined Global "ldexp" referenced in /lib/libc > Undefined Global "ldexp" referenced in /lib/libc > Undefined Global "matherr" referenced in /lib/libc > >--- >Marc Majka - System Manager UBC Computer Science When you installed the 'c' compiler, it loaded a (now) bogus version of /lib/syslib[probably.881]. Find syslib in your AA and copy it into /lib. Reboot, et voila, your problem should be history. Peter Craine, NARC [ BTW, I discovered this same thing when I brough my node to SR10.2, so keep this in mind for the future, folks.] From apollo-request@umix.cc.umich.edu Mon Jul 24 15:38:19 1989 Date: 24 Jul 89 17:57:38 GMT From: majka%moose.cs.ubc.ca%ubc-cs.uucp@beaver.cs.washington.edu (Marc Majka) Organization: UBC Department of Computer Science, Vancouver, B.C., Canada Subject: Re: C Math on DN10000 Message-Id: <4529@ubc-cs.UUCP> References: <8907241157.AA01868@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Many thanks to all who have responded to my request for help with the missing math functions on the DN10000. The problem was solved for me by a very helpful Software Engineer from Apollo Toronto. It seemed that a beta C compiler I had tried out had clobbered /lib/syslib. This was know to be a problem with installing on a SR10.1 node, but I had missed the warning message sent out with the beta tape. I will be executed by a firing squad for this, as soon as I have finished documenting my code :-) --- Marc Majka - Altar Boy of Apollo From apollo-request@umix.cc.umich.edu Mon Jul 24 19:31:46 1989 Date: 24 Jul 89 20:17:37 GMT From: rpbert%phoenix.uucp@princeton.edu (Raymond Pierrehumbert) Organization: Princeton University, NJ Subject: SCSI and eraseable optical drives for DN10000 Message-Id: <9577@phoenix.Princeton.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am getting an Apollo DN10000 soon; among other things I would like to hook a CD-ROM and an eraseable optical (magneto-optical, actually) disk to it. Presumeably, these would be SCSI devices. Does anybody have experience with the SCSI board, if any, for the DN10000? Are CD-ROM (high Sierra) and magneto-optical drivers available for the OS yet? How feasible would it be to use the hardware available for the AT Bus? How would I work the software end of it so as to make the files available to UNIX/NFS? From apollo-request@umix.cc.umich.edu Mon Jul 24 21:36:18 1989 Date: 24 Jul 89 17:54:00 GMT From: tim%hi-csc.uucp@uunet.uu.net (Tim Giebelhaus) Organization: mpls Subject: Re: Possible to mount others disks onto DN10000? Message-Id: <584@tim.UUCP> References: <1709@cunixc.cc.columbia.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1709@cunixc.cc.columbia.edu> micky@cunixc.cc.columbia.edu (Micky Liu) writes: > >I am rather new to these Apollo's, but have been managing Sun's for quite >some time now... Is it possible to mount NFS disks onto the DN10000. I >have looked in the man pages and see that it is possible to remote mount >the DN10000 disks, but I want to mount the disks from my Convex C210 onto >my Apollo. > >After looking around I've found /etc/nfsd, but no corresponding /etc/biod. >Is Apollo's offering of NFS only a one way deal? NFS is a two way deal. The NFS manual is the best NFS manual I have seen yet. I used the Apollo NFS manual to set up some Suns a while ago. Please refer to you manual to see how to get it running. If you do not have the manuals, please ask you salesman where they are. If the product is not performing like the manual states it should, please take advantage of your service contract and call for software help. x x x -- UUCP: uunet!hi-csc!apcimsp!tim ARPA: tim@apollo.com Contents of this message has nothing to do with work. From apollo-request@umix.cc.umich.edu Tue Jul 25 01:22:12 1989 Date: 24 Jul 89 05:08:50 GMT From: nick%pta%metro%otc%munnari.oz.au%uhccux.uucp@ames.arc.nasa.gov (Nick Frisina) Organization: Pyramid Technology Australia, Sydney Subject: NFS - Apollo/Pyramid Message-Id: <527@pta.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi, I recall on the news that NFS between Pyramid OSx4.1 & Apollo SR10.1 was a bit suspect. Has a fix been reported as yet? Could it be posted to me please? nick From apollo-request@umix.cc.umich.edu Tue Jul 25 01:23:46 1989 Date: 24 Jul 89 18:18:00 GMT From: mishkin%apollo%ulowell%mailrus.uucp@purdue.edu (Nathaniel Mishkin) Organization: Apollo Computer, Chelmsford, MA Subject: Re: A comparison of Commercial RPC Systems Message-Id: <449d9889.12879@apollo.COM> References: <6569@joshua.athertn.Atherton.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <6569@joshua.athertn.Atherton.COM> joshua@Atherton.COM (Flame Bait) writes: >I've finished work on a paper entitled "A Comparison of Commercial RPC >Protocols" which I gave at NCF: The Network Computing Forum, and also >as a work in progress at USENIX. > >It compares RPC (Remote Procedure Call) systems from Apollo, Sun and >Netwise for speed and dependablity. I'm posting the paper (in troff >format) to comp.misc, so interested people can get it. ... I am seeking to end any cross-posting concerning this article by posting my response to comp.protocols.misc. I suggest all further discussion take place there. -- -- Nat Mishkin Apollo Computer Inc., Chelmsford, MA mishkin@apollo.com From apollo-request@umix.cc.umich.edu Tue Jul 25 01:29:32 1989 Date: 24 Jul 89 18:41:00 GMT From: nazgul%apollo%ulowell%mailrus.uucp@tut.cis.ohio-state.edu (Kee Hinckley) Organization: Apollo Computer, Chelmsford, MA Subject: Re: more Message-Id: <449dad2c.1b147@apollo.COM> References: <8441@batcomputer.tn.cornell.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8441@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu (Moshe Braner) writes: >[] > >The Apollo "more" tool chooses it's own font, and takes a lot >of time to start up. Quite annoying when, e.g., reading mail >letter by letter (with PAGER=more). Is there an alternative? >Has somebody written a simple "more" that does not do cursor >addressing (and thus escapes the vt100 emulator)? This is a rather technical nit, but in fact more does none of this. More requires the use of a terminal emulator, and pads are not emulators. Thus what you are watching is actually the startup of the vt100 emulator each time you read a mail message. There are several options. You can either let the stuff scroll out, and then scroll back to it, you can use crpad to create a new window with the output, or you can write a pretty trivial application to pop up a read-only pane on the message. There are lots of the latter hanging around, but I don't believe any get shipped. Most people at Apollo do either the first or the third of those choices. I suppose if you want to totally give up padness you could also simply run your mail program from a vt100 emulator. -kee -- ### User Environment, Apollo Computer Inc. ### Public Access ProLine BBS ### ### {mit-eddie,yale}!apollo!nazgul ### nazgul@pro-angmar.cts.com ### ### nazgul@apollo.com ### (617) 641-3722 300/1200/2400 ### I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. From apollo-request@umix.cc.umich.edu Tue Jul 25 11:29:39 1989 Date: Tue, 25 Jul 89 09:37:01 edt From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8907251337.AA09482@richter.mit.edu> To: apollo@umix.cc.umich.edu, rpbert%phoenix.uucp@princeton.edu Subject: Re: SCSI and eraseable optical drives for DN10000 Call Workstation Solutions at (603) 880-0080. They specialize in optical disk drives and SCSI devices. We have one of their Exabyte tape drive packages and we are quite pleased with it. I have also played with their CD-ROM reader (using High Sierra CD's) and one of their worm drives. Both were SCSI devices (as is the Exabyte tape drive) and hhad support for IOS streams (ie. Unix I/O, but not mapped-segment support) file systems. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Tue Jul 25 13:32:07 1989 Date: 25 Jul 89 15:45:11 GMT From: carla@boulder.colorado.edu (Carla Mowers) Organization: University of Colorado, Boulder Subject: Re: A Comparison of Commerical RPC Protocols Message-Id: <10258@boulder.Colorado.EDU> References: <6567@joshua.athertn.Atherton.COM>, <951@anise.acc.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The results presented in Joshua Levy's RPC paper are based on data that is now nearly nine months old. An article I've posted to comp.misc contains some performance measurements based on new releases of both the Netwise and Apollo products. A new Sun product has not been released since Joshua's measurements were made. The article contains data collected in early June of 1989 by Netwise. All source code used for these measurements may be obtained by sending a request to "tony@wldrdg.UUCP". Please direct all other questions and comments to this account as well. This article is being posted from this account due to technical difficulties with the USENET feed at Netwise. Of course, you should probably take any numbers presented here with a large grain of salt. What one party measures doesn't necessarily correlate well to the environment another is interested in. The leap-frog nature of the game means that any measurement won't be valid long. Internally, we have a next- release prototype that improves on the performance of our currently shipping product as, I'm sure, do the other vendors. The suggestion from Lars Poulsen that ASN.1 encodings lead to poor performance isn't necessarily true. Our performance numbers show us approaching Sun's RPC in several areas (opaque buffers still need work), and our current prototype is, at worst, 2% slower than Sun in the categories we tested. The flexibility of ASN.1 can actually be an advantage. Our prototype exploits this for large buffers. By using a longer length form (one byte longer) we can get the ASN.1 buffer aligned such that bcopy() can make the transfer from the user's buffer to the transmission buffer much more quickly. I believe you'll find the posted information basically lacking in hype. If you view this as a commercial use of the net, I'm sorry. I'm simply responding to an article that contained outdated information regarding one of our products. Tony Andrews Netwise, Inc. 2477 55th St. Boulder, CO 80301 Phone:303-442-8280 UUCP: onecom!wldrdg!tony From apollo-request@umix.cc.umich.edu Tue Jul 25 17:31:10 1989 Date: Tue, 25 Jul 89 15:36:25 edt From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8907251936.AA00954@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: help with SR10 senmail We are using the BSD sendmail program on our SR9.7 and SR10.1 machines. On the SR10 machines, we occassionally can not send messages -- we get something similar to the following: $ mail -v krowitz Subject: test abcd *** EOF *** Cc: krowitz... Connecting to .local... mail: mail: can't find mail group krowitz... Sent At At other times, we have no problems sending messages. Does anyone have any ideas about about the "mail: mail: can't find mail group" means? -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Wed Jul 26 09:34:36 1989 Date: 26 Jul 89 10:19:17 GMT From: jnp%newshost%mjolner%santra%tut%draken%kth%mcvax.uucp@uunet.uu.net (J|rgen N|rgaard) Organization: none Subject: Gnu Emacs, X 11.3 and Apollo. Anybody using this ? Message-Id: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I'm trying to use this configuration but experience some problems: Regularily while doing only typing text the editor stops displaying the text on the screen. (It is in the vicinity of 100 characters or multiples). After that only closing the window and re-opening it seem to recover though it some times can happen moving the mouse over the winow a number of times. So: is anybody using Emacs and X on Apollo without problems and what versions of the software is being used ? (My system: Apollo DN 3500 SR 10.1 / BSD4.3 X 11R3 (ADUS modifications) GNU Emacs 18.54 using very little of the Lucid modifications. (No GPR support etc) Thanks in advance -- Regards, J|rgen N|rgaard ('|' is '\o{}' in \LaTeX{}) e-mail: jnp@tele.nokia.fi. telephone: <..>-358-0-511-5671 -- -- -- Regards, J|rgen N|rgaard ('|' is '\o{}' in \LaTeX{}) e-mail: jnp@tele.nokia.fi. telephone: <..>-358-0-511-5671 -- From apollo-request@umix.cc.umich.edu Wed Jul 26 19:27:09 1989 Date: 26 Jul 89 19:45:00 GMT From: mishkin%apollo.uucp@EDDIE.MIT.EDU (Nathaniel Mishkin) Organization: Apollo Computer, Chelmsford, MA Subject: Re: A Comparison of Commerical RPC Protocols Message-Id: <44a7f591.1d6d5@apollo.COM> References: <6567@joshua.athertn.Atherton.COM>, <951@anise.acc.com>, <10258@boulder.Colorado.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I'm trying (as I did in my previous posting) to cut down the cross-posting here. Let's try to move the rest of this conversation to comp.protocols.misc. In article <10258@boulder.Colorado.EDU> carla@boulder.Colorado.EDU (Carla Mowers) writes: >The results presented in Joshua Levy's RPC paper are based on data that is >now nearly nine months old. An article I've posted to comp.misc contains >some performance measurements based on new releases of both the Netwise >and Apollo products. A new Sun product has not been released since Joshua's >measurements were made. Actually, the NCS versions (1.0 and 1.1) are more or less the same, in terms of functionality and performance. You don't want to know the mess that's been made of version numbers. Apollo OS versions sr10.1 and later have a newer version of NCS with improved bulk data performance. (This version is called NCS 1.5.) These improvements will also appear in a new NCS version running on Apollo (sr10.2) and non-Apollos and will be called NCS 1.5.1. >Of course, you should probably take any numbers presented here with a large >grain of salt. What one party measures doesn't necessarily correlate well to >the environment another is interested in. Some grains of salt: The data reported in your paper was obtained by running client and server on the same machine. I have to take a fair bit of exception with this. I would imagine that the time to make a remote call is dominated (or at least significantly determined by) the networking costs (i.e. the cost of sending and receiving network messages). The cost of sending intra-machine network messages can be assumed to be roughly zero (relative to the inter-machine cost, anyway). Your tests may thus have measured the relative speeds of things that are a small fraction of the total cost of making a remote call. -- -- Nat Mishkin Apollo Computer Inc., Chelmsford, MA mishkin@apollo.com From apollo-request@umix.cc.umich.edu Wed Jul 26 23:31:13 1989 Date: 27 Jul 89 01:22:00 GMT From: conliffe%caen.engin.umich.edu%mailrus.uucp@csd4.milw.wisc.edu (Darryl C. Conliffe) Organization: U of M Engineering, Ann Arbor, Mich. Subject: Porting to SR10.1 Message-Id: <44a922e3.14df5@ulsoy.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Well, it looks like we'll be biting the bullet sooner than expected, and going from SR9.7 to SR10.1. I will be porting a system that employs Dialog, 2D GMR, Pascal, and FORTRAN, with the source code managed by a DSEE library. Could the port be a simple matter of recompiling on SR10 machines with SR10 compilers? Anyone with comments, suggestions, or sympathy? BTW, I know about Open-DIALOG, but need to port this way first; we may move to it next release. -- ___________________ Darryl C. Conliffe conliffe@caen.engin.umich.edu (313) 721-6069 ------------------- From apollo-request@umix.cc.umich.edu Wed Jul 26 23:32:25 1989 Date: 27 Jul 89 01:16:00 GMT From: conliffe%caen.engin.umich.edu%mailrus.uucp@csd4.milw.wisc.edu (Darryl C. Conliffe) Organization: U of M Engineering, Ann Arbor, Mich. Subject: Re: A Comparison of Commerical RPC Protocols Message-Id: <44a91cd9.14df5@ulsoy.engin.umich.edu> References: <6567@joshua.athertn.Atherton.COM>, <951@anise.acc.com>, <44a7f591.1d6d5@apollo.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Noting your responses to the RPC article, Nat, can you tell me if NCS represents -only- a specialized RPC functionality, or is there more to the product? -- ___________________ Darryl C. Conliffe conliffe@caen.engin.umich.edu (313) 721-6069 ------------------- From apollo-request@umix.cc.umich.edu Thu Jul 27 11:28:59 1989 Date: 27 Jul 89 14:37:59 GMT From: tom%fangorn%dftsrv.uucp@ames.arc.nasa.gov (Thomas D. Schardt) Organization: NSESCC, Goddard Space Flight Center, Greenbelt MD Subject: Re: sr10.1 Install on Stand-Alone Nodes (an APR) Message-Id: <402@dftsrv.gsfc.nasa.gov> References: <12868@well.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I whole-heartily agree with Richard Friedman's description of what needs to be done to improve OS installations on stand-alone Apollo system. As I attempted to install SR10.1 on our DN3500, the thought of dragging the machine to the roof and pitching it over the side crossed my mind. I didn't, but the experience has left a bad taste in my mouth when it comes to that machine. Tom Schardt Bitnet: K4TDS at SCFVM NASA/Goddard Space Flight Center Internet: K4TDS@SCFVM.GSFC.NASA.GOV Code 632 Opinions expressed are my own and do not Greenbelt, MD 20771 necessarily reflect the opinions of my employer From apollo-request@umix.cc.umich.edu Thu Jul 27 11:44:18 1989 Date: 26 Jul 89 19:30:46 GMT From: rchrd%well.uucp@apple.com (Richard Friedman) Organization: RCHRD 2855 Telegraph #415 Berkeley CA 94705 Subject: sr10.1 Install on Stand-Alone Nodes (an APR) Message-Id: <12868@well.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The following is a copy of an APR regarding the system load/install procedure for sr10.1 on stand-alone nodes. This APR was issued as a request for improvement ("enhancement"). The installation procedure for DOMAIN 10.1 on stand-alone (disked) nodes is seriously flawed. Anyone attempting to install the operating system on a node that has no partner is faced with some very anxious hours. In my recent experiences with 10.1, it took many re-attempts before the system was properly installed. The following is offered to the team at Apollo that deals with the installation procedures as a friendly attempt to make them more aware of the particular problems facing the owner/user of a stand-alone node in the hope they can be improved in later releases. A number of issues are addressed in this APR, and rather than send separate APR's, I have bundled them together into one. First, let me say that my experiences over the past weeks trying to get 10.1 installed on a stand-alone DN3000 lead me to think that no one at Apollo ever tried to do such an installation, and that the procedures reflect the installation team's lack of experience in this area. The situations typically facing the administrator of stand-alone nodes are: 1. First-time installation of 10.1 from a 9.x system. (This will require INVOL'd the disk.) 2. Hardware problem with disk requires INVOL of disk (or, as in my recent case, replacement with new disk). The fact that there is no network and no partner node, the only source of software is the system release materials. I should also mention that it takes about 4 hours to install DOMAIN and the FTN and CC compilers from cartridge tapes on a DN3000, starting with a format/write/read-back INVOL on a 170Mb disk. (That's a long time!) [1] No Diagnostics on Boot Tape Consider the following: Disk crashes repeatedly, due to real hardware problem. Crashes have made mince-meat out of system on disk. It won't boot properly, nor will diagnostics in /sau8 run. Only recourse is to INVOL disk and re-install system from cartridges. Would like to be able to run diagnostics before attempting the install in order to determine cause of problem. However, the boot system (on tape) does not include any diagnostics, only INVOL, SALVOL, CALENDAR, and DOMAIN. This means the only way diagnostics can be run after the disk is INVOL'd is by first doing a complete install of the operating system, which may fail due to the hardware problem. Suggestion: Include, along with system distribution tapes, a diagnostic tape. (Obviously, this tape would have to include all the sau's.) An initialization procedure could prompt the user for configuration. This tape must be bootable as a self-contained system, making no assumptions about what is already on the disk. [2] Need System Backup/Restore Procedure On a stand-alone node, should disk problems occur requiring an INVOL or disk replacement, there is no way to restore the system except by doing a complete re-installation. Doing this is not only an extreme waste of time (it may take more than one re-install to get it right), but it also loses any customizations of the running system that the system adminstrator may have done since the system was last installed. Doing a re-install of the system from the installation media is not something an adminstrator is likely to look forward to doing. Suggestion: Provide a system backup/restore procedure. Once the system is installed and customized, a backup system can be produced as a bootable tape. Booting from this tape regenerates the system on the disk. Later, the adminstrator can reload his user data backup tapes. Having a system backup procedure is preferred to merely saving the MINST configuration files to control the system installation. The administrator has no idea how MINST works, and shouldn't need to. The minimal DOMAIN system that comes up from the distributed boot system immediately puts the user into MINST. To do something extra to read in the saved config files is too much too much to ask! [3] Streamline the Install Procedure for Stand-Alone Nodes The "Authorized Area" concept is ridiculous for stand-alone nodes. There is no reason why the install procedure must be partitioned into load and install operations. They should be combined into one operation on stand-alone nodes. MINST should ask at the start if this is an install on a stand-alone node. Then it need only to ask what system options are to be selected, and then load/install accordingly. There is no reason to load into the /install directory and make links. The load should be directly to the proper system directories. Also, only the selected parts of the system need be loaded. With the current MINST, even though I have selected only SAU8, it loads ALL the sau's, but installs only sau8 into the root directory with links. This is true for the other parts of the system I deselect: they get loaded into /install, but the links are not made. To conserve disk space after the install I must (very carefully!) delete items from /install. This should not be necessary! Only the installation tools should be loaded into /install on a stand-alone node load/install. The system should be installed in its proper place. After installation I should feel confident that rm -r /install will not get me into trouble, and will recover disk space successfully. [4] Recovering from an Install that Went Bad If something goes wrong during the load/install procedure (wrong answer given, tape read error, user error, etc.) there is no way to confidently restart the install without going all the way back to an INVOL. Suppose something goes wrong and MINST exits with errors. Without knowing the exact parameters that the canned procedure used to start up MINST, there is no way to manually restart MINST properly. For one thing, MINST and INSTALL++ must be more forgiving and robust. The WORST thing they can do is just exit! They must be restartable, or at least indicate to the user how to restart and proceed. [5] Documentation! Much could be said about Apollo's documentation of the system install process. None of it would be good, and I am glad to hear that the documentation is being re-done. Here are some suggestions: o It would be very valuable, when explaining the questions that MINST and INSTALL put to the administrator, to indicate the implications of each of the possible answers. There are many instances when you ask yourself, "What happens if I say yes?!". The documentation doesn't give a clue. o Rather than issue Installation Notes that say "Disregard the 3rd paragraph on page 27 of the Installation Guide", issue change pages that update the installation guide! Currently, before attempting the installation, I had to read 3 documents, each one updating and correcting details in the one previous. The psychological damage to one's confidence that the installation procedure is workable creates tremendous anxiety and additional unneeded stress in those of us that are forced undertake these trials. o Include an appendix that explains and suggests procedures for installing and maintaining system software on stand-alone nodes. I suspect that there are a good enough number of such configurations to justify at least an appendix. It should be written by someone who has actually and successfully installed and customized the system on a stand-alone node. Some of the issues mentioned in this APR need to be addressed in this appendix: -- How to do the install efficiently -- What can be ignored, and what is required for a stand-alone node. -- Which daemons are not needed. Which are? -- Recovering disk space after the install -- How to set up a simple registry. -- Doing backups.. what needs to be saved. [6] Misleading INSTALL++ Question Deletes System! After successfully installing DOMAIN once, I went on to install FTN and CC compilers. Running INSTALL++ I was confronted with the questions: "Would you like to recover disk space by deleting the following OS branches: 1. os " Of course I would! I assumed that this was going to delete all the secondary links to the operating system that are in /install. And, after answering yes, I saw INSTALL go on to delete all the links to the operating system that were in the /install directory. Fine! BUT, then it went on to delete all the primary links as well. I watched in horror as the operating system leaked out onto the floor and I was left with nothing but 4 hours wasted. I quickly opened another a window and tried the ls command: % ls ls: command not found. All was lost! And its because none of this is properly described in the documentation (What is an OS branch, as far as INSTALL is concerned?) And, because INSTALL should not have asked! (This is a stand-alone system, remember??) (You can imagine my state of composure after this happened! "Hacker goes Berserk! Axes Computer!") --------------- I hope this information is helpful in improving the day-to-day life of those of us with stand-alone nodes. Please do not hesitate to call on me for further information. PS: The opinions expressed herein are my own and do not in any way represent those of my employer, Pacific-Sierra Research Corp. -> Richard Friedman (415) 540-5216 END TEXT SET DESCRIPTION END APOLLO PRODUCT REPORT -- ...Richard Friedman rchrd@well.uucp (Pacific-Sierra Research/Berkeley, CA.) also: {lll-crg,pacbell,hplabs}!well!rchrd From apollo-request@umix.cc.umich.edu Thu Jul 27 13:35:44 1989 Date: 26 Jul 89 13:40:57 GMT From: schmidt%cadlab%pbinfo%unido%mcvax.uucp@uunet.uu.net (Michael Schmidt) Organization: CADLAB / Uni-GH Paderborn, Germany Subject: Subnetting and Routing Problems Message-Id: <506@cadlab.cadlab.de> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu After installing Class B Internet numbers with a subnet mask of 255.255.254.0 we encountered problems with routing. Perhaps somebody out there can give us a hint. Machines: SUN 3 SunOS 4.0.1, SunOS 3.5 Apollo 3000/3500 AEGIS 9.7 (Networking version 3.2) Nixdorf Targon/35 (Pyramid) TOS 3.3.03 I don't know, whether the Targon OS No. is the same, Pyramid called ist. But I really would like to know that. Network: Apollo token ring, gateway Apollo on an Ethernet with Sun's and Targon/35's, one of them has a SLIP connection to another SUN. Situation: Targons and Apollos get the routing tables of the Apollo. Fine. Sun don't get the routing tables. Bad. Routed gets a response to its request, but after 3 minutes, all is dead again. So apparently the Sun don't get the broadcasts of the Apollo. The Targon with the SLIP connection broadcasts over the SLIP. OK. But on the ethernet, nothing is heard by all the other machines. What is going on here? Any idea? -- Michael Schmidt, CADLAB / FB 17, Uni-GH Paderborn, Bahnhofstr. 32, D-4790 Paderborn, West Germany Mail: schmidt@cadlab.UUCP or schmidt@cadlab.cadlab.de From apollo-request@umix.cc.umich.edu Thu Jul 27 13:48:22 1989 Date: 26 Jul 89 15:38:24 GMT From: schmidt%cadlab%pbinfo%unido%mcvax.uucp@uunet.uu.net (Michael Schmidt) Organization: CADLAB / Uni-GH Paderborn, Germany Subject: How can I get the Ethernet No. of an Apollo Message-Id: <507@cadlab.cadlab.de> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have 3com Ethernet boards in one of our Apollos. Can any kind soul tell me, how I can get the Ethernet No. of one of these boards? -- Michael Schmidt, CADLAB / FB 17, Uni-GH Paderborn, Bahnhofstr. 32, D-4790 Paderborn, West Germany Mail: schmidt@cadlab.UUCP or schmidt@cadlab.cadlab.de From apollo-request@umix.cc.umich.edu Thu Jul 27 17:31:09 1989 Date: 27 Jul 89 18:09:41 GMT From: adam@cu-arpa.cs.cornell.edu (Adam Feigin) Organization: Cornell National Supercomputer Facility Subject: Re: How can I get the Ethernet No. of an Apollo Message-Id: <30427@cornell.UUCP> References: <507@cadlab.cadlab.de> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu try 'arp ' where is the name of the host you want to know the ethernet address of. See the man page for arp AWF ----------------------------------------------------------------------------- Internet: feigin@tcgould.tn.cornell.edu Adam Feigin UUCP: {backbones}!cornell!batcomputer!feigin Workstation Consultant MaBell: (607) 255-3985 Cornell National Supercomputer Facility From apollo-request@umix.cc.umich.edu Thu Jul 27 17:34:59 1989 Date: Thu, 27 Jul 89 15:46:34 edt From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8907271946.AA03592@richter.mit.edu> To: conliffe%caen.engin.umich.edu%mailrus.uucp@csd4.milw.wisc.edu Subject: Re: Porting to SR10.1 Cc: apollo@umix.cc.umich.edu Fortan code will probably be ok. The default compiler optimization level (ie. if you do not supply a -OPT on the command line) seems to have changed from -OPT 1 to -OPT 3. Fortran I/O files have changed. If you create a formatted file (ie. ascii output), you will now get a file with a file-type of UNSTRUCT, rather than UASC. If you create an unformatted file (ie. binary data), you will get a file with a file-type of UASC, rather than REC. The Fortran I/O system is able to handle both the old SR9.7 files and the new SR10 ones (although how it distinguishes between an SR9.7 UASC file (containing ascii text) and an SR10 UASC file (containing binary data) is beyond me). There is a bonus in this ... the SR10 unformatted files seem to have the same record format as the files created by Sun, Alliant, and other machines which use IEEE format floating point numbers. The older REC files have to be run throught the sendrec and getrec programs available from the ADUS library before you can use them with a non-Apollo system. We have been able to copy unformatted Fortran data files between our Alliant and our SR10 Apollos with no conversion and we have been able to read the files with no problems. There is only 1 caveat: if you create a direct-access unformatted file and write a record which is smaller than the record size of the direct access file, the Apollos seem to pad the record with garbage and the Alliant and Sun-3 systems seem to pad the record with zeroes. Sequential-access files and direct-access files which have every record filled can be run through /bin/diff or /com/cmf with no problems. ... I just did a quick test ... our SR9.7 nodes seem to be able to read the unformatted Fortran I/O files created on the SR10 machines. 2-D GMR was changed between SR9.7 (where it was bundled with the OS) and SR10 (where it is now a seperate product). SR9 came with GMR version 1.0, SR10.1 comes with version 2.2 They are *not* compatible. The GMR metafiles format is different and the text handling and line style calls have been changed. About a half-dozen GMR calls relating to fonts, text, and line styles have been deleted and replaced by an "environment file" mechanism. There is a good chance that this will break your program since almost everyone uses some text and/or line style stuff in their GMR applications. I have not noticed anything new with the Pascal compiler to worry about. I can't say anything about DSEE and Dialog, as we don't use them here. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Thu Jul 27 19:28:30 1989 Date: 27 Jul 89 17:14:31 GMT From: paul%kuhub.cc.ukans.edu%wupost%wugate%wuarchive%brutus.cs.uiuc.edu.uucp@tut.cis.ohio-state. (Craig Paul) Organization: University of Kansas Academic Computing Services Subject: Increasing disk storage on Apollos - NFS?? Message-Id: <6772@kuhub.cc.ukans.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We are contemplating adding massive amounts of disk storage to be used for our Apollos. How well do disk servers from various companies do (using NFS)? Comments on Apollo disk servers are also welcome! Can one specify an NFS mounted directory as the "home" of an Apollo user in the registry? A second question: Can one easily attach files from an Aegis (Apollo Unix) floppy disk into his directory path (such as with a mount command)? Thank you! From apollo-request@umix.cc.umich.edu Thu Jul 27 23:45:31 1989 Date: 27 Jul 89 22:39:48 GMT From: ianh%merlin%bruce%munnari.oz.au%uhccux.uucp@ames.arc.nasa.gov (Ian Hoyle) Organization: none Subject: Re: C Math on DN10000 Message-Id: <955@merlin.bhpmrl.oz> References: <2512@ubc-cs.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >From article <2512@ubc-cs.UUCP>, by majka@moose.cs.ubc.ca (Marc Majka): > Help! I recently upgraded our DN10000 from 10.0 to 10.1, and > all the C math functions have disappeared. For example: > [stuff deleted] > I've called the hotline about this. The languages group > eventually gave up and declared that it was a system problem. > The system group has no idea what is going on. I can't > believe that this is happening on every DN10000 which is > running SR10.1.p! The library files /lib/syslib and > /lib/clib are there, but something must be missing. Any > help would be greatly appreciated! yep, it happened here to :-( We had to reinstall from our AA, the 10.0 version of syslib. However I'm informed that the system runs slower with this old syslib (any comments out there ??) - it sure seems like it does. Somebody has *really* goofed on this one ...... I hope it all gets properly rectified when we get (at long last) REAL compilers for the 10000. ian BTW has anyone seen the Omniback/8mm tape thingie for the 10000 yet ?? We are waiting for delivery on ours so I'm keen to find out about others experiences with it. -- 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 Thu Jul 27 23:46:06 1989 Date: 27 Jul 89 20:42:27 GMT From: abair%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Alan Bair) Organization: SPS CAD, Motorola Inc., Austin, Texas. Subject: Re: sr10.1 Install on Stand-Alone Nodes (an APR) Message-Id: References: <12868@well.UUCP>, <402@dftsrv.gsfc.nasa.gov> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I also agree with many of Richard's problems. I would especially like to emphasize the problem of determing just how to install the OS to use the least amount of disk space; hard links or copy. If you use hard links it is not clear whether there is actually a space saving. Then if you do a copy, erasing the /install is the next step, but what can be erased. Just a little more information would be handy. Even large networks could make use of this information. If there is one thing I hate about installation software, its when facts about what is being done or how items are related are hidden from the user. I can understand not telling much as a default, but I should have a option to ask for it or read about it. Please consider all of these ideas and proposals in a positive light. Alan Bair SPS CAD Austin, Texas Motorola, Inc. UUCP cs.utexas.edu!oakhill!turbinia!abair From apollo-request@umix.cc.umich.edu Fri Jul 28 05:25:38 1989 Date: 27 Jul 89 20:51:35 GMT From: rchrd%well.uucp@apple.com (Richard Friedman) Organization: RCHRD 2855 Telegraph #415 Berkeley CA 94705 Subject: Stand-Alone Nodes! Please Identify Yrselves!! Message-Id: <12879@well.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am trying to put together an unofficial and highly unscientific profile of the problems that those of use who have to manage stand-alone Apollo nodes. The information gathered here will be sent on to Apollo in the hopes that the system installation and management features of DOMAIN 10.x will be improved in regards to the particular problems of stand-alone nodes. Let me define a stand-alone node as an Apollo system that is not connected to any other apollo, except perhaps a diskless node. Typically it will have its own, unshared disk. The only communication links might be via dialup lines, etc. But there is no network connected, and no network is even close enought to be connected termporarily. You may have seen my recent apr on the problems of installing Domain on my stand alone DN3000. Please comment on this and any problems you might be having that I did not consider. Please constrain your comments to those problems that are particular to the stand-alone configuration (i.e. there is no other disk to download from). I will summarize these comments and issue the result in a few weeks. Please e-mail to the address shown in the header, or to rchrd@well.com Feel free to call me if necessary at 415 540 5216 (Pacific time zone). This activity is being done in a friendly manner to gather information about how their products are received by those of us in the trenches. -- ...Richard Friedman rchrd@well.uucp (Pacific-Sierra Research/Berkeley, CA.) also: {lll-crg,pacbell,hplabs}!well!rchrd From apollo-request@umix.cc.umich.edu Fri Jul 28 05:31:16 1989 Date: 27 Jul 89 19:58:10 GMT From: mlm%calmasd%ucsdhub%hp-sdd.uucp@hplabs.hp.com (Monte Meals) Organization: Calma - A Division of Prime Computer, San Diego, CA Subject: Re: Porting to SR10.1 Message-Id: <453@calmasd.Prime.COM> References: <44a922e3.14df5@ulsoy.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <44a922e3.14df5@ulsoy.engin.umich.edu>, conliffe@caen.engin.umich.edu (Darryl C. Conliffe) writes: > > Well, it looks like we'll be biting the bullet sooner than > expected, and going from SR9.7 to SR10.1. > ... Could the port be a simple matter of > recompiling on SR10 machines with SR10 compilers? I believe Apollo has a rather complete porting guide listing problem areas. Some of the problems include file path names and character case. Some of the tools (like the linker) are also different and can present problems. Monte From apollo-request@umix.cc.umich.edu Fri Jul 28 13:28:47 1989 Date: 28 Jul 89 15:31:39 GMT From: turner%dover%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Robert Turner) Organization: Motorola Inc., Sector CAD, Mesa, AZ Subject: Aliases For Aegis Commands Message-Id: <1632@dover.sps.mot.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu First I know this is a wimpy question, but what the heck. I'm an old Aegis kind of guy slowing migrating to BSD on SR10+. What I'm looking for is a set of aliases for some of the more common Aegis commands, e.g. cpf, dlf, dlt, crd, crl, wd, etc. My fingers keep typing Aegis commands while my brain is saying BSD, BSD, BSD! Yes I know it would be a good learning exercise to create them myself, but being a good and lazy programmer I'd like to steal from someone else. Any suggestions? Robert -- Robert Turner (602) 994-6837 ...!uunet!dover!turner or turner@dover.sps.mot.com Horngren's Observation: Among economists, the real world is often a special case. From apollo-request@umix.cc.umich.edu Fri Jul 28 15:22:38 1989 Date: 28 Jul 89 08:50:23 GMT From: schmidt%cadlab%pbinfo%unido%mcvax.uucp@uunet.uu.net (Michael Schmidt) Organization: CADLAB / Uni-GH Paderborn, Germany Subject: Re: Subnetting and Routing Problems Message-Id: <510@cadlab.cadlab.de> References: <506@cadlab.cadlab.de> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <506@cadlab.cadlab.de>, schmidt@cadlab (Michael Schmidt) writes: > >After installing Class B Internet numbers with a subnet mask of >255.255.254.0 we encountered problems with routing. Perhaps >somebody out there can give us a hint. Solved it (in a way): I gave all "ifconfig"'s a "broadcast " and all is working fine now. Thanks for the hints. -- Michael Schmidt, CADLAB / FB 17, Uni-GH Paderborn, Bahnhofstr. 32, D-4790 Paderborn, West Germany Mail: schmidt@cadlab.UUCP or schmidt@cadlab.cadlab.de From apollo-request@umix.cc.umich.edu Fri Jul 28 15:32:50 1989 Date: 28 Jul 89 17:39:49 GMT From: glass%mica.berkeley.edu%agate.uucp@ucbvax.Berkeley.EDU Organization: University of California, Berkeley Subject: File Sharing and UNIX Diskless Workstations Message-Id: <26742@agate.BERKELEY.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I've been asked to write an essay on how clusters of diskless UNIX workstations manage to share file systems -- without stepping on one another's "toes" and maintaining their individual identities. There are two issues here. The first is: How do manufacturers arrange the file system so that the files which give the machines their individual identities appear different to each machine, while others are shared? Remember that, due to the ad-hoc growth of UNIX, many configuration files are in the same directories as data files, utilities, and applications that can and should be shared. Second, how does a server handle diskless clients with different architectures (or running different versions of the OS)? For example, a Sun 4 can't use the same binaries as a Sun 3 -- and if the server is a VAX, it will need separate binaries as well. I've begun to get a handle on how Sun addresses this problem in SunOS 4.0 (though more info would be welcome). However, I have no idea how (or if) Apollo, ULTRIX, HP, Sequent (which really is a network in a box), AIX, A/UX, POSIX, and OSF propose to handle these problems. (I have heard that the Apollo machines implement some trick whereby environment variables can be included in the pathnames of files, but the person who mentioned this to me didn't know any of the details, nor how pervasive this technique was.) If you have insights on how any or all UNIX implementations address these problems, please respond to this posting and/or send me mail. I'm sending this query to a broad cross-section of newsgroups in an attempt to learn about many different techniques, but since following up to all those groups would cause a great deal of traffic, I've set the Followup-To: line to point at comp.unix.questions. I will summarize (and perhaps interject some ideas) in the essay, which I hope to publish shortly. ============================================================================ "One of the nicest things about mathematics, or anything else you might care to learn, is that many of the things which can never be, often are." Norton Juster, "The Phantom Tollbooth" ============================================================================ From apollo-request@umix.cc.umich.edu Fri Jul 28 15:38:22 1989 Date: 28 Jul 89 18:16:12 GMT From: glass%mica.berkeley.edu%agate.uucp@ucbvax.Berkeley.EDU Organization: University of California, Berkeley Subject: File Sharing and UNIX Diskless Workstations Message-Id: <26747@agate.BERKELEY.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I've been asked to write an essay on how clusters of diskless UNIX workstations manage to share file systems -- without stepping on one another's "toes" and maintaining their individual identities. There are two issues here. The first is: How do manufacturers arrange the file system so that the files which give the machines their individual identities appear different to each machine, while others are shared? Remember that, due to the ad-hoc growth of UNIX, many configuration files are in the same directories as data files, utilities, and applications that can and should be shared. Second, how does a server handle diskless clients with different architectures (or running different versions of the OS)? For example, a Sun 4 can't use the same binaries as a Sun 3 -- and if the server is a VAX, it will need separate binaries as well. I've begun to get a handle on how Sun addresses this problem in SunOS 4.0 (though more info would be welcome). However, I have no idea how (or if) Apollo, ULTRIX, HP, Sequent (which really is a network in a box), AIX, A/UX, POSIX, and OSF propose to handle these problems. (I have heard that the Apollo machines implement some trick whereby environment variables can be included in the pathnames of files, but the person who mentioned this to me didn't know any of the details, nor how pervasive this technique was.) If you have insights on how any or all UNIX implementations address these problems, please send mail. I will summarize (and perhaps interject some ideas) in the essay, which I hope to publish shortly. ============================================================================ "One of the nicest things about mathematics, or anything else you might care to learn, is that many of the things which can never be, often are." Norton Juster, "The Phantom Tollbooth" ============================================================================ From apollo-request@umix.cc.umich.edu Fri Jul 28 19:36:40 1989 Date: 27 Jul 89 16:03:42 GMT From: postnews%tubsibr%infbs%unido%mcvax.uucp@uunet.uu.net (Stefan Petri) Organization: TU Braunschweig, Informatik, Bueltenweg, W. Germany Subject: Re: Subnetting and Routing Problems Message-Id: <1989Jul27.160342.13786@tubsibr.uucp> References: <506@cadlab.cadlab.de> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <506@cadlab.cadlab.de> schmidt@cadlab.UUCP (Michael Schmidt) writes: > >After installing Class B Internet numbers with a subnet mask of >255.255.254.0 we encountered problems with routing. Perhaps >somebody out there can give us a hint. > > >Machines: > > SUN 3 SunOS 4.0.1, SunOS 3.5 > Apollo 3000/3500 AEGIS 9.7 (Networking version 3.2) > Nixdorf Targon/35 (Pyramid) TOS 3.3.03 > Our Machines : Nixdorf Targon/35 (Pyramid) TOS 3.2.00 , NSP 3.2.01 SUN 3 SunOS 4.0 SIEMENS PC SINIX 2.0, SINIX 5.? All on a single Ethernet, but we are using class A adresses. >I don't know, whether the Targon OS No. is the same, Pyramid >called ist. But I really would like to know that. > So would I. > >Situation: > >Targons and Apollos get the routing tables of the Apollo. Fine. > >Sun don't get the routing tables. Bad. Routed gets a response to >its request, but after 3 minutes, all is dead again. So >apparently the Sun don't get the broadcasts of the Apollo. > >The Targon with the SLIP connection broadcasts over the SLIP. OK. >But on the ethernet, nothing is heard by all the other machines. > We had a similar problem with `rwhod' until we changed our broadcast-address : ( from /etc/rc.local : ) # TODO: Define any machine host and network names here, # then check the "ifconfig" commands. ENET0=$HOST # ENET1=${HOST}-alt BROAD0=89.00.00.00 # BROAD1=altnet-broad NETMASK0=0xff000000 # NETMASK1=0xffffff00 We don't use the routed, and we never tested it, but try exchanging '00's and 'ff's in your broadcast-addresses. Also the ".254." in your subnet-address looks a bit strange to me. ^ Stefan Petri Technische Universitaet Braunschweig, Institut fuer Betriebssysteme und Rechnerverbund, 3300 Braunschweig, W. Germany. Early to rise and early to bed makes a man healthy, wealthy and dead. From apollo-request@umix.cc.umich.edu Sat Jul 29 05:24:33 1989 Message-Id: <8907290144.AA22809@umix.cc.umich.edu> Date: Sat, 29 Jul 89 09:44:06 SST From: fclim Subject: Re: Aliases for Aegis Commands To: One ADU to another In article <1632@dover.sps.mot.com>, turner%dover%oakhill%cs.utexas .edu.uucp@tut.cis.ohio-state.edu (Robert Turner) > First I know this is a wimpy question, but what the heck. I'm > an old Aegis kind of guy slowing migrating to BSD on SR10+. > What I'm looking for is a set of aliases for some of the more > common Aegis commands, e.g. cpf, dlf, dlt, crd, crl, wd, etc. > My fingers keep typing Aegis commands while my brain is saying > BSD, BSD, BSD! > > Yes I know it would be a good learning exercise to create them > myself, but being a good and lazy programmer I'd like to steal > from someone else. > > Any suggestions? > > Robert I have setup my path to include /com in my ~/.cshrc : set path = (.... /com) This way, I do not need aliases for Aegis commands. However because cd is built-in to csh and wd is built-in to /com/sh at SR10+ (hmm, wonder if there is a /com/wd), I have to alias wd 'cd !*' Futhermore, because ld (in /bin) is homonymous with /com/ld, I have alias ld 'ls !*' Note you could use alias ld '/com/ld !*' However, my ls has an alias of alias ls 'ls -AF !*' which tells whether an object is a sub-dir, executable file, FIFO, symbolic links or just a plain file. Another pair of homonymous commands is help (/usr/bin/help for SCCS and /com/help). Sometimes, I need help on ACLs, so I need to type in help protection rights To get the right "help", I have the alias alias help '/com/help !*' If you are worried that you do not have the security of cpf, mvf, chn, etc, use alias cp 'cp -i !*' alias mv 'mv -i !*' alias rm 'rm -i !*' This will not copy files over existing ones. Hope this helps. fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. From apollo-request@umix.cc.umich.edu Sat Jul 29 05:25:47 1989 Message-Id: <8907290755.AA27040@umix.cc.umich.edu> Date: Sat, 29 Jul 89 15:51:32 SST From: fclim Subject: Re: Aliases for Aegis Commands To: One ADU to another Here's another alias for csh. It implements the Korn shell feature of cd-ing to the previous working directory : % pwd foo % cd bar ; pwd bar % cd - ; pwd foo % cd - ; pwd bar I'm not sure if the 4.3BSD csh has this feature, but it's certainly not available on 4.2BSD (SR9.7). Anyway, you need to add this to your ~/.cshrc set prev = ~ as well as the alias alias cd set tmp = $cwd; if (!* == -) cd $prev; if (!* != -) cd !*; set prev = $tmp; unset tmp Please note that I have split the alias into several lines to show the structure. But you have to put them on a single line; it won't work if the alias is over several lines. It's a kludge which I don't know how to get round (just look at the ulgy double comparisons of !* with -). alias cd 'set tmp = $cwd; if (!* == -) ... $tmp; unset tmp' BTW, a good book to invest in is The Unix C Shell Field Guide Gail and Paul Anderson Prentice-Hall ISBN 0-13-937468-X 025 Look up the gt and gb aliases in section 6.3 on page 125-126. Here's a interesting feature that you'll not find using /com/sh. We all know how useful ` (back-quote) is; especially for sys_admin personnel. $ wd `node_data will put you into the /sys/node_data directory of the node you are working on. However, if you need to go into the node_data dir of a different node, you have to give the full pathname starting from the network root : $ wd //london/sys/node_data This is what I did to maintain my reputation for laziness. Firstly, I did this (only once) % mkdir ~/nd ; cd ~/nd % foreach x (//*) ? ln -s $x/sys/node_data $x:t ? end Thus, I now have ~/nd/london as a link to //london/sys/node_data. Next, I put in my ~/.cshrc set cdpath = (~/nd) (See the Andersons' book on the concept of cdpath which is also available on Bourne and Korn Shells.) Now, I am set up for life. No matter where I am, if I want to get to //london/sys/node_data, I just type in % cd london This feature also works with pushd : % pushd london will get me to london while keeping a record of where I have been. fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. From apollo-request@umix.cc.umich.edu Sun Jul 30 01:22:19 1989 Date: 28 Jul 89 16:38:54 GMT From: rchrd%well%pacbell%amdahl.uucp@ames.arc.nasa.gov (Richard Friedman) Organization: RCHRD 2855 Telegraph #415 Berkeley CA 94705 Subject: Re: Stand-Alone Nodes! Please Identify Yrselves!! Message-Id: <12897@well.UUCP> References: <12879@well.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <12879@well.UUCP> rchrd@well.UUCP (Richard Friedman) writes: >I am trying to put together an unofficial and highly unscientific >profile of the problems that those of use who have to manage >stand-alone Apollo nodes. >Please e-mail to the address shown in the header, or to > rchrd@well.com ==> Perhaps a more correct e-mail address would be: rchrd@well.sf.ca.us or even rchrd@well.uucp -- ...Richard Friedman rchrd@well.uucp (Pacific-Sierra Research/Berkeley, CA.) also: {lll-crg,pacbell,hplabs}!well!rchrd From apollo-request@umix.cc.umich.edu Sun Jul 30 07:23:18 1989 Date: 30 Jul 89 01:35:37 GMT From: achille%cernvax%mcvax.uucp@uunet.uu.net (achille petrilli) Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Subject: Curses/vt100 emulator on sr10.1 Message-Id: <1041@cernvax.UUCP> References: <8907290755.AA27040@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi, I've got the following problem and am wondering if somebody can help me: I installed sr10.1 on a dn3000, everything fine, and then discovered that curses did not work in a pad. We have a program that uses curses and runs on sr10 on other machines (dn3000s as well) all fine. Now I checked the vt100 emulator and that works fine, vi (it does not use curses) is fine, our program instead starts up removing, as normal, the input bottom pad, and then keeps scrolling instead od doing home, clear screen etc. I looked around for some standard program using curses and found /usr/games/canfield, this does exactly the same as our pgm. I checked time stamps on obvious libs but didn't find anything clearly wrong. The other dn3000s where I tested the pgm are different in one way: we installed sr10.0 and then sr10.1 incremental on them, whether the new one has got sr10.1 directly. Any idea ? The same happened some time ago on a dn10000, apparently when going to sr10.1 as well, our local guy fixed it and now he has left Apollo, so I'm pretty much stuck. Please send replies to dore@cernapo.cern.ch as I'll be away for two weeks Thanks in advance. Achille Petrilli Cray and PWS Operation From apollo-request@umix.cc.umich.edu Sun Jul 30 07:24:41 1989 Date: 30 Jul 89 01:20:14 GMT From: achille%cernvax%mcvax.uucp@uunet.uu.net (achille petrilli) Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Subject: Install problems Message-Id: <1040@cernvax.UUCP> References: <12879@well.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I would like to throw in my 2 cents thoughts about install. I can't speak about stand-alone install, but having a network does not solve any of the problem Richard was talking about, just makes things a little bit better (i.e. no need to fiddle around with tapes). -) Doc is pretty poor, I cannot agree more. I like to know what a program does, you can imagine how I'd love to know about all the install beasties ! -) Another big problem is protections: apparently you get the system shipped on disk installed as 'open'; the only way to close the system now is by invol'ing and re-installing (for stand-alone owners' pleasure), (this is the only way we figured out). -) You customize rc.local et al., install 10.1 and get all of 'em overwritten ! no warning, no anything, just scrapped. -) No info on what should be saved in /install to keep track of what's been installed: I'd like to save all necessary files, say, every night and have a way to run automatically install++ from those files if/when the disk is lost/upgraded/etc. I couldn't find anything clear about that. I was told that everything was gonna be rosy with the new install programs, for the time being this is partially true. On the other side the old install was a series of shell scripts, without doc you could figure out what was happening to your disks (and fix bugs ... :-) Hope this helps in getting a better install++, Achille Petrilli Cray & PWS Operations From apollo-request@umix.cc.umich.edu Sun Jul 30 07:30:03 1989 Date: 29 Jul 89 17:14:25 GMT From: gors%well.uucp@hplabs.hp.com (Gordon Stewart) Organization: Whole Earth 'Lectronic Link, Sausalito, CA Subject: Re: How can I get the Ethernet No. of an Apollo Message-Id: <12912@well.UUCP> References: <507@cadlab.cadlab.de> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu 3COM supplies diagnostics diskettes for its IBM PC XT/AT -slot products that are in executable, 8086 code -- Among the things this code (3C503.EXE) does is the reporting of the five hex bytes of the ethernet address. It may seem like brute force, but if you don't get help from 3COM (have you contacted them directly?) you could slip the card into an IBM -- I have the software and could e-mail it to you. -- {apple, pacbell, hplabs, ucbvax}!well!gors gors@well.sf.ca.us (Doolan) | (Meyer) | (Sierchio) | (Stewart) From apollo-request@umix.cc.umich.edu Sun Jul 30 17:23:07 1989 Date: 30 Jul 89 18:45:00 GMT From: hucka%caen.engin.umich.edu%mailrus.uucp@tut.cis.ohio-state.edu (Michael Hucka) Organization: U of M Engineering, Ann Arbor, Mich. Subject: Problem with nonblocking sockets under SR9.7 Message-Id: <44bbddee.1707d@giskard.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I'm encountering a problem with sockets which I hope someone more experienced can help me with. My experience with sockets is limited, so this problem may be due to my own error, but after spending hours in the debugger watching this program, it really seems like a bug in DOMAIN/IX sockets. It concerns enabling/disabling blocking mode on sockets in the internet domain, under SR 9.7. I've written a small server-like program which creates a socket and listens on a port for two connections. The best arrangement for this program is if it can selectively set the sockets non-blocking for part of the time, and blocking at other times. The problem is that although it can create a socket, accept a connection and then set the (new) socket non-blocking, trying to set it *back* to blocking mode just doesn't seem to work. I've tried both ioctl with FIONBIO and fcntl with FNDELAY and neither of them seem to have any effect; they return valid status but the socket ends up staying non-blocking. Here are code fragments for the two ways I've tried: socket_blocking_mode(sock, mode) int sock, mode; { int flags; flags = (mode ? 0 : 1); if ( ioctl(sock, FIONBIO, &flags) < 0 ) error(); else return; } --------------------- alternate ---------------------------- socket_blocking_mode(sock, mode) int sock, mode; { int flags; /* Set the descriptor status flags to enable/disable blocking I/O. * Note that doing the fcntl call in the form documented in the * Unix 4.3BSD Advanced IPC manual, i.e., fcntl(sock, F_SETFL, FNDELAY) * doesn't work at all; the third arg is apparently really a flag * and so we must first get its current value then bit-or/and with * the desired flag. */ if ((flags = fcntl(sock, F_GETFL, 0)) < 0) error(); if (mode) flags |= FNDELAY; else flags &= ~FNDELAY; if (fcntl(sock, F_SETFL, flags) < 0) error(); } --------------------------- Can anyone offer suggetions as to what might be going on here? I have not had the chance to try this under SR10. Any help or suggestions will be much appreciated. Mike Hucka University of Michigan -- Mike Hucka Computer Aided Engineering Network, Univ. of Michigan, Ann Arbor MI 48109 ARPA: hucka@caen.engin.umich.edu. ----------------------------------------------------------------------------- From apollo-request@umix.cc.umich.edu Mon Jul 31 09:34:12 1989 Date: 31 Jul 89 03:17:30 GMT From: steve%simon%obdient%laidbak%att.uucp@ucbvax.Berkeley.EDU (Steven E. Piette) Organization: ACT, Inc., Dank Dark Cave, Algonquin, IL. Subject: Re: Aliases for Aegis Commands Message-Id: <348@simon.UUCP> References: <8907290144.AA22809@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8907290144.AA22809@umix.cc.umich.edu>, GBOPOLY1@NUSVM.BITNET (fclim) writes: > In article <1632@dover.sps.mot.com>, turner%dover%oakhill%cs.utexas > .edu.uucp@tut.cis.ohio-state.edu (Robert Turner) > > > What I'm looking for is a set of aliases for some of the more > > common Aegis commands. > > > > Robert > > However because cd is built-in to csh and wd is built-in to /com/sh > at SR10+ (hmm, wonder if there is a /com/wd), I have to > alias wd 'cd !*' > > fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu In fact there used to be a /com/wd under AEGIS before SR10. At SR10 AEGIS processes changed to the UNIX single program per process model. An external wd command would have forked a process from the shell, changed the working directory in the new process space, and then exited back to the shell where the old working dir is still set. This is exactly what happened at prior OS releases when you were in a UNIX enviroment and used "WD" instead of the shell intrinsic "CD" to move the directory pointer. Many old AEGIS people use to take advantage of the fact that a program could change the enviroment of the parent. Not that this was a good practice, but it had lots of uses once I found out the rules had changed from other systems I had worked on. -- Steven E. Piette Applied Computer Technology Inc. UUCP: {smarthost}!simon!steve 1750 Riverwood Drive INET: steve@simon.CHI.IL.US or spiette@SUN.COM Algonquin, IL 60102 ------------------------------------------------------------------------------- From lubkin@apollo.com Mon Jul 31 11:24:06 1989 From: David Lubkin Message-Id: <8907311551.AA25049@xuucp.ch.apollo.com> Date: Mon, 31 Jul 89 11:39:21 EDT Subject: INFO-DSEE mail To: dsee_list:@apollo.com From: robinson Date: mon, 10 jul 89 11:12:23 Subject: Re: INFO-DSEE mail Date: mon, 10 jul 89 09:16:00 From: derstad@cim-vax.honeywell.com ("DAVE ERSTAD") Subject: DSEE Difficulties This is being cross-posted to dsee-list and info-apollo; I'm not sure if the membership is a complete overlap. Here's a laundry list of DSEE problems Apollo didn't tell you about... (Or at least didn't tell *me* about). Most are various version compatibility problems. 1) DSEE 3.2.1 is supposed to be compatible with SR9.7 or later. Actually, you need SR9.7.0.4 or later. If you are running 9.7.0.3, the D3M server will abort with a message telling you that the node is not at 9.7 or later. This is due to some naming call added at 9.7.0.4 which needs to be present. Actually this is a very good thing. The SR9.7 releases prior to SR9.7.0.4 were broken and DSEE can not guarantee the consistency of the library database with the version history database on those releases. SR9.7.0.4 was the first release of the SR9.7 line with a fix to the problem. 2) DSEE 3.3.1 does not appear to be as compatible with 3.2.1 as advertised. Specifically, we have found that if one has a DSEE shell node at 9.7 DSEE builder node at 10.0 DSEE reference node at 9.7 OR DSEE shell node at 10.0 DSEE builder node at 9.7 DSEE reference node at 9.7 then DSEE is sometimes (possibly always; I just can't prove/disprove that) unable to locate derived objects from previous builds for use in current builds (our specific derived objects are insert files for Pascal applications). This is not a case sensitivity problem, and we do have DOWNCASE set in the ENVIRONMENT section. It should be noted that this problem disappears with DSEE 3.3.2.p, and presumably with DSEE 3.3.2 although we don't have that yet. The SR9.7 shipped Pascal compiler will not work correctly in the environments you describe. There was a newer release of the SR9.7 Pascal compiler shipped with SR10.x: $ sr9.7_compatibility/compat_with_sr9.7/com/pas -version pas (Pascal Compiler), revision 7.3814 contains a fix to the problem you describe. There are other similar problems with cross-major-revision work (the most general of which is that some type-managers found in /sys/mgrs will not work across the SR9.7/SR10 boundry) and all that I have seen have been caused by translators and NOT DSEE. It is important when determining which tool is at fault to determine if each tool in a chain is doing what it claims to do. In this case I believe that you would have seen that DSEE *was* correctly creating an environment variable in the process of the translation but the translator (the Pascal compiler) was NOT using the environment variable properly. This could have been noted by adding a statement to your translate rule to dump the environment variables at the start of the translation and noting that the EV *was* there and contained the appropriate value. If the above translator does not solve this problem then further information about your situation will be necessary. 3) The compiled models used by 3.3.2.p are not compatible with 3.2.1. Presumably, this also means 3.3.2 is not compatible with 3.2.1, although again we haven't verified that. DSEE versions { V3.3.2, V3.2.2, and V3.3.2.p } are compatible with each other and incompatible with prior releases as far as compiled system models and pools are concerned due to critical bug fixing. As a rule we never like to ship incompatible versions of DSEE and we try to make the incompatibilities seemless but there are times when this is not possible: this was one of those times. Douglas B. Robinson Apollo Computer A Subsidiary of Hewlett-Packard MS CHA-01-LT 508/256-6600 x6225 15 Elizabeth Drive ARPA: robinson@apollo.com Chelmsford, MA 01824 UUCP: {decwrl!decvax, mit-eddie, attunix}!apollo!robinson ====================================================================== Post to info-dsee@apollo.com Administrative mail to info-dsee-request@apollo.com ====================================================================== ------- From apollo-request@umix.cc.umich.edu Mon Jul 31 13:27:18 1989 Date: 31 Jul 89 14:59:28 GMT From: ss%chip.uucp@nosc.mil (Steve Schossow) Organization: M/A-COM Government Systems Inc., San Diego, CA Subject: vt_100 config file? Message-Id: <261@chip.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I'm also interested in getting the fonts I want out of the vt100 emulator. I did a dmpf on /sys/vtserver (the vt100 server program) and found a reference to: ~user_data/vt100_config I assumed this was documented somewhere but haven't found it anywhere. Anyone care to dig into this? Partial dump of /sys/vtserver: ----------------------------------------------------------- 001560: FCD8 4E90 4CEE 3CFC FE04 4E5E 4E75 003E ..N.L.<...N^Nu.> 001570: 0017 0004 7674 3130 306C 7674 3130 3073 ....vt100lvt100s 001580: 0006 0100 0007 0003 0000 0754 7E75 7365 ...........T~use 001590: 725F 6461 7461 2F76 7431 3030 5F63 6F6E r_data/vt100_con 0015A0: 6669 6700 00FF 0200 00FF 00FF 0000 0000 fig............. 0015B0: 41E0 550E FFFF FFFF FFFF FFFF FFFF FFFF A.U............. 0015C0: FFFF FFFF 0000 0000 7674 3130 306C 2020 ........vt100l 0015D0: 2020 2020 2020 2020 2020 2020 2020 2020 ... 14 copies of the preceding line ... 0016C0: 2020 2020 2020 2020 7674 3130 3073 2020 vt100s 0016D0: 2020 2020 2020 2020 2020 2020 2020 2020 ... 14 copies of the preceding line ... 0017C0: 2020 2020 2020 2020 4E56 FF20 48E7 3C34 NV. H.<4 From apollo-request@umix.cc.umich.edu Mon Jul 31 15:24:18 1989 Date: 31 Jul 89 17:17:44 GMT From: ajk%mace.cc.purdue.edu%mentor.cc.purdue.edu.uucp@purdue.edu (Jeff Boerio) Organization: Tg Programming Subject: Tape Drives Message-Id: <2819@mace.cc.purdue.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hello, we are interested in purchasing a single Apollo DN3500 computer, and a tape backup system. However, we are somewhat confused. Is there any difference between the Apollo tape system and the Danford tape system? Thanks for your response. - Jeff Boerio -- Jeff Boerio: ajk@mace.cc.purdue.edu Purdue University Department of Computer Science Purdue University Computing Center Summer Work: University of Cincinnati, Dept. of Materials Science From apollo-request@umix.cc.umich.edu Mon Jul 31 17:30:55 1989 Date: 31 Jul 89 17:59:38 GMT From: taylor@cs.ucla.edu (Charles Taylor) Organization: UCLA Computer Science Department Subject: GNU CC on Apollo 10.1? Message-Id: <26119@shemp.CS.UCLA.EDU> References: <261@chip.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I got the recently posted kit of programs needed to run GNU CC on an Apollo under SR 10.1. I'm right now in the middle of building it, and I'd like to know one thing before I go on: Do I need to port and compile the GNU assembler (gas) as well in order to run GNU CC? If anybody's successfully gotten GNU CC to work, I'd appreciate it if you'd drop me a note and tell me what you had to do... Thanks, Matt Kennel kennel@cognet.ucla.edu From apollo-request@umix.cc.umich.edu Mon Jul 31 19:22:43 1989 Date: 31 Jul 89 20:40:21 GMT From: reesd%gtephx%hrc%asuvax.uucp@handies.ucar.edu (David Rees) Organization: AG Communication Systems, Phoenix, Arizona Subject: Re: Aliases For Aegis Commands Message-Id: <44c14aa1.f9df@gtephx.UUCP> References: <1632@dover.sps.mot.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1632@dover.sps.mot.com>, turner@dover.sps.mot.com (Robert Turner) writes: > First I know this is a wimpy question, but what the heck. I'm > an old Aegis kind of guy slowing migrating to BSD on SR10+. > What I'm looking for is a set of aliases for some of the more > common Aegis commands, e.g. cpf, dlf, dlt, crd, crl, wd, etc. > My fingers keep typing Aegis commands while my brain is saying > BSD, BSD, BSD! First of all you must be carefull when making aliases for aegis to unix or the other way around. For instance I tried to make an alias for cpf: %alias cp cpf This is WRONG! First of all cpf does all its copying in pairs while cp copies all the items to the last item. $cpf F1 F2 F3 F4 F1 -> F2 (F1 is copied to F2) F3 -> F4 (F3 is copied to F4) %cp F1 F2 F3 F4/ F1 F2 F3 -> F4 (They are copied into F4) And second of all with the Unix shells (Bourne and C) the regular expressions are expanded by the shell, while in Aegis it seems like the expressions are expanded by the command. For instance I typed the following: %cpf ?*.c ./backup -r <--- DON'T DO THIS! While this is right out of the manual I missed a critical detail. The '%' instead of the '$'. Since the C shell expanded the wildcard first, it sent cpf a list of the files and then cpf proceeded to replace every other file (about three weeks worth of work, thank god for backups). A rule I follow is, NEVER alias an AEGIS command as a Unix command (or the reverse). The two systems are just not that much alike. I would suggest getting used to cp, rm -r (dlt) etc. In addition to the wild carding ect., the options go after instead of before. It would be much easier for you to learn the Unix commands. Here is a list of similar commands (I wouldn't alias them.....) cpf cp (Not very similar) dlf rm dlt rm -r (Recursive remove) crd mkdir crl ln -s (Symbolic link, I think the target and source are switched in these) wd pwd Perhaps you could make an alias that instead of performing the command, echos to you the correct command to use. i.e. %alias dlt 'echo Use rm' -David BTW, I used the standard that a '$' prompt is an AEGIS shell and that a '%' is an C (Unix) shell. BTW2, are you no longer able to access AEGIS commands by giving the path (/com/cpf) after SR10? I am still on SR9.7. From apollo-request@umix.cc.umich.edu Mon Jul 31 21:19:49 1989 Date: 31 Jul 89 23:43:57 GMT From: daemon%jarvis.csri.toronto.edu%mailrus.uucp@iuvax.cs.indiana.edu (Chris Siebenmann) Organization: Ziebmef home away from home Subject: Re: A Comparison of Commerical RPC Protocols Message-Id: <89Jul31.194335edt.30760@snow.white.toronto.edu> References: <951@anise.acc.com>, <10258@boulder.Colorado.EDU>, <44a7f591.1d6d5@apollo.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu mishkin@apollo.com (Nathaniel Mishkin) writes: | I would imagine that the time to make a remote call is dominated (or | at least significantly determined by) the networking costs (i.e. the | cost of sending and receiving network messages). At least with Sun's RPC running over tcp, this is not the case as I discovered to my surprise last summer. If you're exchanging structured data, the networking overhead is completely swamped by XDR overhead, even for Sun<->Sun connections using only integers. -- "I shall clasp my hands together and bow to the corners of the world." Number Ten Ox, "Bridge of Birds" Chris Siebenmann ...!utgpu!{ncrcan,ontmoh!moore}!ziebmef!cks cks@white.toronto.edu or ...!utgpu!{,csri!}cks From apollo-request@umix.cc.umich.edu Mon Jul 31 21:24:33 1989 Date: 31 Jul 89 21:03:52 GMT From: mlm%calmasd%ucsdhub.uucp@ucsd.edu (Monte Meals) Organization: Calma - A Division of Prime Computer, San Diego, CA Subject: Re: vt_100 config file? Message-Id: <465@calmasd.Prime.COM> References: <261@chip.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu > vt100 emulator. I did a dmpf on /sys/vtserver (the vt100 > server program) and found a reference to: > > ~user_data/vt100_config > Looks like vt100_config might be part of an obsolete structure to switch the KBD_$F1 and KBD_$L1 keys. Character fonts are rather simple. If you want full VT100 support, you need to have the fonts vt100s and vt100l in /sys/dm/fonts. The emulator will pick which ever one is closer in height to your currently loaded font. If vt100s or vt100l are not present, the vt100 character functions "bold," "blink," and others will not work. Monte From apollo-request@umix.cc.umich.edu Tue Aug 1 09:31:37 1989 Date: 1 Aug 89 06:45:32 GMT From: Sam_Mayday_Malone%cup.portal.com%portal.uucp@uunet.uu.net Organization: The Portal System (TM) Subject: DN3000 1Meg Memory For Sale Message-Id: <20915@cup.portal.com> References: <44bbddee.1707d@giskard.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hello to the net. I have 10 1 Meg memory boards for an Apollo DN3000 for sale. If you are interested in beefing up your node a little bit these can be had for $100 a piece or all 10 for $700. They are the original Apollo boards (Apollo Part No. 7109) and are for sale only because we have upgraded to all 2 Meg boards. All were removed from nodes and have been tested as being fully working. If you are interested, Email here would be welcome. Thanks Sam_Mayday_Malone@cup.portal.com "Who *is* that guy?" "Who *gives* a rat's rump?" From lubkin@apollo.com Tue Aug 1 10:52:15 1989 From: David Lubkin Message-Id: <8908011511.AA02798@xuucp.ch.apollo.com> Date: Tue, 1 Aug 89 11:01:58 EDT Subject: INFO-DSEE mail To: dsee_list:@apollo.com Date: mon, 31 jul 89 19:28:00 From: derstad@cim-vax.honeywell.com ("DAVE ERSTAD") Subject: Re: DSEE Version compabilibilities > > 1) DSEE 3.2.1 is supposed to be compatible with SR9.7 or later. > > Actually, you need SR9.7.0.4 or later. If you are running 9.7.0.3, > > the D3M server will abort with a message telling you that the > > node is not at 9.7 or later. This is due to some naming > > call added at 9.7.0.4 which needs to be present. > Actually this is a very good thing. The SR9.7 releases prior to SR9.7.0.4 > were broken and DSEE can not guarantee the consistency of the library > database with the version history database on those releases. SR9.7.0.4 > was the first release of the SR9.7 line with a fix to the problem. The reason this is not a good thing is o The error message said 9.7, not 9.7.0.4 (actually some error messages said SR9 only!). o All published documentation/release notes said the release was SR9.7 compatible My problem is not that 9.7.0.4 was required. My problem is that the documentation was WRONG, the error message was WRONG, and it took weeks to track this down, despite reasonably diligent efforts from my hotline support person. I don't expect Apollo to test every piece of software with every possible version of everything else, but if they say something is 9.7 compatible I expect it to be tested with 9.7. If it has only been tested with 9.7.0.4, that should be documented. This is an important distinction to note, since many customers never loaded 9.7.0.4. > The SR9.7 shipped Pascal compiler will not work correctly in the > environments you describe. There was a newer release of the SR9.7 > Pascal compiler shipped with SR10.x: > > $ sr9.7_compatibility/compat_with_sr9.7/com/pas -version > pas (Pascal Compiler), revision 7.3814 > > contains a fix to the problem you describe. There are other > similar problems with cross-major-revision work (the most > general of which is that some type-managers found in /sys/mgrs > will not work across the SR9.7/SR10 boundry) and all that > I have seen have been caused by translators and NOT DSEE. Yes, we had determined this after the previous posting. BTW, these things need to be pointed out to the hotline support people. > > 3) The compiled models used by 3.3.2.p are not compatible with > > 3.2.1. Presumably, this also means 3.3.2 is not compatible > > with 3.2.1, although again we haven't verified that. > DSEE versions { V3.3.2, V3.2.2, and V3.3.2.p } are compatible with > each other and incompatible with prior releases as far as compiled > system models and pools are concerned due to critical bug fixing. > > As a rule we never like to ship incompatible versions of DSEE and > we try to make the incompatibilities seemless but there are times > when this is not possible: this was one of those times. OK, but then don't put statements in the release notes like > Objects created by DSEE Versions 3.2, 3.3, 3.2.1, and 3.3.1 are fully > compatible with objects created by DSEE Versions 3.2.2 and 3.3.2. The implication to me is that we can run 3.3.2 on our SR10 nodes and 3.2.1 on our SR9.7 nodes with no loss of functionality/efficiency, which isn't true. I should mention that DSEE is darn near essential to my productivity. In general, I'm in love with DSEE. I'm just annoyed that these sorts of things weren't better documented, and so difficult to track down. Dave Erstad Principal Design Automation Engineer Honeywell SSEC ====================================================================== Post to info-dsee@apollo.com Administrative mail to info-dsee-request@apollo.com ====================================================================== ------- From apollo-request@umix.cc.umich.edu Tue Aug 1 15:06:00 1989 Date: 31 Jul 89 17:20:58 GMT From: vince%bcsaic%ssc-vax%fluke.uucp@beaver.cs.washington.edu (Vince Skahan) Organization: Boeing Computer Services - Phila. Subject: Re: Stand-Alone Nodes! Please Identify Yrselves!! Message-Id: <13605@bcsaic.UUCP> References: <12879@well.UUCP>, <12897@well.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I share many of your concerns andcomments regarding setting up SR10 on the first node but personally, I didn't have too many problems that weren't mentioned in the customer service bulletin that went out to everyone concerning RAI except for the fact that the "ok to delete the os to save space ?" message very nearly nailed me (good thing I chickened out rather than answering YES). Compared to SR9, I though under 4 hours to invol, install, and configure everything was pretty great. We had the same problems you seem to have had relating to "which daemons do we run". It wound up we ran all the SR9 stuff plus the rgyd, glbd, and llbd... -- Vince Skahan Boeing Computer Services - Phila. (215) 591-4116 ARPA: skahan@boeing.com UUCP: bcsaic!skahan Note: the opinions expressed above are mine and have no connection to Boeing... From apollo-request@umix.cc.umich.edu Tue Aug 1 15:08:01 1989 Date: 31 Jul 89 17:11:38 GMT From: vince%bcsaic%ssc-vax%fluke.uucp@beaver.cs.washington.edu (Vince Skahan) Organization: Boeing Computer Services - Phila. Subject: domain protocol over twisted pair Message-Id: <13604@bcsaic.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We run a variety of rings of Apollos and a number of ethernet-only Apollos on a campus ethernet. Each Apollo can talk to each other via Apollo token ring protocol via the appropriate rtsvc commands. We have experienced what we think are performance problems between rings (relative to the speed of a token-ring) that appear to be far in excess of the expected difference (10MB vs 12 MB coax). Our ethernet connections are either straight drop cables off of the campus fiber, thinwire ethernet ultimately off of a tap into the fiber, or LatticeNet over twisted pair. Apollo informs us that running Apollo over Latticenet is not supported since that means it's over twisted pair (and that's what's really not officially supported). Does anyone have any information about any of the following ? - should we see definite slowness between rings regardless of how the rings are connected to ethernet ? we remember a definite perceived slowness of "native apollo" relative to the old "etherbridge" product. - should we see a special drop in performance over Latticenet (is anyone using Apollo over laticcenet. ?)? - if Latticenet is "real ethernet" why isn't it officially supported? We need good technical reasons to make the networking folks take notice. - should we see any difference in performance from node to node if the nodes are on Latticenet relative to them being on drop cables - should we see perceptable (real perceptable) slowness going over ethern to copy files, do backups, copy large trees with lots of small files, etc. ? - what is the REAL minimum speed of the ethernet to enable reasonable apollo-apollo communications without experiencing network timeouts ? We have one bulding remotely located with a link that is about 1/2 of T-1 speed. We experience lots of network timeouts between down there and the rest of the ethernet. When you consider that we have a registry site down there, it takes forever to add accounts, change passwords, etc. ===> any help would be greatlyapreciated. Feel free to either e-mail or post followups as you wish... -- Vince Skahan Boeing Computer Services - Phila. (215) 591-4116 ARPA: skahan@boeing.com UUCP: bcsaic!skahan Note: the opinions expressed above are mine and have no connection to Boeing... From apollo-request@umix.cc.umich.edu Tue Aug 1 19:08:15 1989 Date: 1 Aug 89 04:03:44 GMT From: root%simon%obdient%laidbak%att.uucp@ucbvax.Berkeley.EDU (Local Deity) Organization: ACT, Inc., Dank Dark Cave, Algonquin, IL. Subject: Re: How can I get the Ethernet No. of an Apollo Message-Id: <349@simon.UUCP> References: <507@cadlab.cadlab.de> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <507@cadlab.cadlab.de>, schmidt@cadlab.uucp (Michael Schmidt) writes: > We have 3com Ethernet boards in one of our Apollos. Can any kind > soul tell me, how I can get the Ethernet No. of one of these boards? > -- On all of the 3com boards I have seen in the U.S. the Ethernet address is located on the board in two places. On the back of the board, there is a label in English that specifies the "NETWORK ADDRESS". This number has two parts; an assigned prefix that identifies the interface as being manufactured by 3com, and a unique part that identifies the specific board. This second part of the address is also located on the small prom chip that encodes the address. On a 3c505 card the first part of the address is 02.60.8C and the prom is at U17. A 3c503 card will have a similar set of lables. If the system is up and running you can find out the Ethernet address by using the arp command available under UNIX. From apollo-request@umix.cc.umich.edu Tue Aug 1 19:10:38 1989 Date: 1 Aug 89 20:40:05 GMT From: rob%agate.berkeley.edu%agate.uucp@ucbvax.Berkeley.EDU (Rob Robertson) Organization: University of California, Berkeley Subject: need MX version of sendmail for apollos Message-Id: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu i'm in the process of configuring a local apollo kluster for mail and i need to find either patches to sendmail v5.61 to get it to run under s10.1 or complete sources. anyone have any? also if anyone has any great ideas for sharing a common /usr/spool/mail, with sendmail running on just one node, i'm all ears. rob -- william robertson rob@violet.berkeley.edu symbolic links are the GOTO's of filesystems From apollo-request@umix.cc.umich.edu Tue Aug 1 19:18:19 1989 Date: Tue, 1 Aug 89 18:21:52 edt From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8908012221.AA05657@richter.mit.edu> To: apollo@umix.cc.umich.edu, vince%bcsaic%ssc-vax%fluke.uucp@beaver.cs.washington.edu Subject: Re: domain protocol over twisted pair A few comments ... 1) MIT's telecommunications office runs the campus-wide ethernet system which our Apollo ringnet is attached to via a DN660 gateway. The telecom office states that the maximum throughput of an ethernet segment is 3 MB/sec on a 10 Mhz thick ethernet cable. This is due to packet collisions eating up network bandwith. Thus, the maximum capacity of our building ethernet (a thick cable network) is 1/4 of the capacity of our 12 Mhz ringnet. (please excuse my typo ... ethernet throughput is 3 Mhz/sec). Apollo talking to each other over native ethernet connections will see a lot of collisions on a heavily loaded network. Apollos on native ringnets which are attached to each other via an ethernet backbone will also see a bottleneck. 2) Network throughput is directly proportional to the number of gateways seperating the nodes. Since the gateways are Apollo workstations and not dedicated hardwired boxes, the time lag to pass a packet from the ringnet interface to the ethernet interface is considerable. This is why diskless node service, /com/lcnode, /com/lusr, and other time dependent network services only work on your local network even if internet routing has been enabled. 3) Paging from diskless nodes and remote file access can eat up network bandwith in a hurry. Try running /com/dspst -a sometime while your node is copying a file to another node's disk. The number of paging requests per second can easily exceed 100/sec. If we assume a page size of 1024 bytes, 8 bits/byte, and 100 pages/sec we see that a single node can consume 0.8 Mhz of bandwith -- almost 25% of the usable bandwith of an ethernet! Now try copying two or three files at once (in seperate windows). You can easily get a single node to generate 200 or 300 paging requests per second!! -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Wed Aug 2 11:53:09 1989 Date: 1 Aug 89 13:30:28 GMT From: lambert%cheops%elecvax%usage%basser%metro%otc%munnari.oz.au%uhccux.uucp@ames.arc.nasa.gov (Timothy Lambert) Organization: EE & CS, Uni N.S.W., Sydney, Australia Subject: Play life on a bitmap Message-Id: <1203@cheops.eecs.unsw.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If you get tired of melting your screen, then you can bring it to life! ------------------cut here---------------------------- program life(input,output); {This program plays Conway's game of life in a window (or on whole screen if you specify -borrow). Pixels with the value of one are regarded as alive and pixels with a value of 0 are regarded as dead. All the calculating of the next generation are done using bit-blts, so that the whole screen is done "in parallel". If you give life the name of a bitmap file it will copy it to the window and play life on it. You can bring your favourite picture to life! Copyright 1989 Tim Lambert lambert@spectrum.eecs.unsw.oz You can do whatever you want with this program provided you leave this notice intact. BUGS: Doesn't work properly on text windows on colour nodes because xi doesn't save such windows properly. Only enlivens plane 0 on colour nodes which doesn't look that good. } %nolist; %include '/sys/ins/base.ins.pas'; %include '/sys/ins/pgm.ins.pas'; %include '/sys/ins/gpr.ins.pas'; %include '/sys/ins/gmf.ins.pas'; %include '/sys/ins/ios.ins.pas'; %include '/sys/ins/pad.ins.pas'; %include '/sys/ins/kbd.ins.pas'; %include '/sys/ins/name.ins.pas'; %include '/sys/ins/error.ins.pas'; %list; type file_name_type = varying[128] of char; VAR status : status_$t; {all GPR calls return a status value indicating whether they've succeeded or failed} mode : gpr_$display_mode_t := gpr_$direct; {direct means we'll be drawing inside a window} display_bitmap : gpr_$bitmap_desc_t; display_size : gpr_$offset_t := [gpr_$max_x_size,gpr_$max_y_size]; {x and y size of our window for drawing in} {we ask for maximum possible bitmap size - GPR reduces this to fit our window} display_hi_plane : gpr_$rgb_plane_t := gpr_$highest_plane; {number of highest plane on screen - 7 for 8 plane nodes 1 for monochrome nodes. we ask for maximum no of planes - GPR reduces this to fit} bitmap_name : file_name_type := '/tmp/life_temp.gmf'; {name of bitmap file} no_of_args : integer; {no of arguments to life (counting argument 0) } arg_pointer : pgm_$argv_ptr; {pointer to the arguments - not used} dm_copy_image : file_name_type := 'au;xi -f '; {append a file name to this and the DM will copy an image to that file} PROCEDURE check(IN messagex : string); {if last system call was unsuccesful prints an error message} BEGIN if status.all <> status_$ok then begin error_$print (status); writeln('error occurred while ',messagex); end; {if} END; procedure acquire; {acquire display if in direct mode} begin if mode = gpr_$direct then discard(gpr_$acquire_display( status )); end; procedure release; {release display if in direct mode} begin if mode = gpr_$direct then gpr_$release_display( status ); end; procedure life_bitmap(bitmap : gpr_$bitmap_desc_t); const quit_set=['q','Q',KBD_$EXIT,KBD_$ABORT]; {stop if any of these keys pressed} var size : gpr_$offset_t; hi_plane : gpr_$rgb_plane_t; source : gpr_$window_t; {specifies origin and size of rectangular region of bitmap to copied from (to)} sourceleft : gpr_$window_t; {specifies origin and size of rectangular region of bitmap to copied from (to)} sourceup : gpr_$window_t; {specifies origin and size of rectangular region of bitmap to copied from (to)} dest : static gpr_$position_t := [0,0]; {destinition point for our bit-blts} destright : static gpr_$position_t := [1,0]; destdown : static gpr_$position_t := [0,1]; temp : gpr_$bitmap_desc_t; {bitmap for temporary results} {let A be original bitmap, B A shifted one bit to left, C A shifted one bit right} {three0 is low order bit of A+B+C and three1 is high order bit} three0 : gpr_$bitmap_desc_t; {three0 := A xor B xor C} three1 : gpr_$bitmap_desc_t; {three1 := (A and (B xor C)) or (B and C) = carry(A,B,C)} {now if D,E,F are A,B,C shifted up one bit and G,H,I down one bit sum0 is low bit of A+B+C+D+E+F+G+H+I sum1 is next bit (2s) sum2 is next bit (4s) we don't care about 8s bit} {using three0D for three0 shifted down and three0U for three0 shifted up} sum0 : gpr_$bitmap_desc_t; {sum0 := three0 xor three0D xor three0U} carry : gpr_$bitmap_desc_t; {carry := carry(three0,three0U,three0D)} sum1 : gpr_$bitmap_desc_t; {sum1 := carry xor three1 xor three1D xor three1U} sum2 : gpr_$bitmap_desc_t; {three1 := ((carry xor three1) and (three1U xor three1D)) xor (carry and three1) xor (three1U and three1D)} attribs : gpr_$attribute_desc_t; {an attribute block for memory bitmaps} event_type : gpr_$event_t; event_data : char; pos : gpr_$position_t; begin gpr_$enable_input(gpr_$keystroke,quit_set,status); check('enable'); gpr_$raster_op_prim_set([gpr_$rop_blt, gpr_$rop_line, gpr_$rop_fill],status); gpr_$inq_bitmap_dimensions( bitmap, size, hi_plane, status ); {find out how big our window is} source.window_base := dest; {we plan to bit_blt the whole} source.window_size := size; {bitmap file} sourceleft.window_base := destright; sourceleft.window_size.y_size := size.y_size; sourceleft.window_size.x_size := size.x_size - 1; sourceup.window_base := destdown; sourceup.window_size.y_size := size.y_size - 1; sourceup.window_size.x_size := size.x_size; gpr_$allocate_attribute_block( attribs, status ); check('allocate'); gpr_$allocate_bitmap(size,0,attribs,temp,status); check('allocate'); gpr_$allocate_bitmap(size,0,attribs,three0,status); check('allocate'); gpr_$allocate_bitmap(size,0,attribs,three1,status); check('allocate'); gpr_$allocate_bitmap(size,0,attribs,sum0,status); check('allocate'); gpr_$allocate_bitmap(size,0,attribs,carry,status); check('allocate'); gpr_$allocate_bitmap(size,0,attribs,sum1,status); check('allocate'); gpr_$allocate_bitmap(size,0,attribs,sum2,status); check('allocate'); repeat gpr_$set_bitmap(three0,status); gpr_$set_raster_op(0,gpr_$rop_src,status); {this is the default but set it anyway} gpr_$bit_blt(bitmap,sourceleft,0,dest,0,status); {three0 := B} check('bit_blt1'); gpr_$set_raster_op(0,gpr_$rop_src_xor_dst,status); gpr_$bit_blt(bitmap,source,0,destright,0,status); {three0 := B xor C} check('bit_blt2'); gpr_$set_bitmap(temp,status); gpr_$set_raster_op(0,gpr_$rop_src,status); gpr_$bit_blt(bitmap,sourceleft,0,dest,0,status); {temp := B} check('bit_blt3'); gpr_$set_raster_op(0,gpr_$rop_src_and_dst,status); gpr_$bit_blt(bitmap,source,0,destright,0,status); {temp := B and C} check('bit_blt4'); gpr_$set_bitmap(three1,status); gpr_$set_raster_op(0,gpr_$rop_src,status); gpr_$bit_blt(bitmap,source,0,dest,0,status); {three1 := A} check('bit_blt5'); gpr_$set_raster_op(0,gpr_$rop_src_and_dst,status); gpr_$bit_blt(three0,source,0,dest,0,status); {three1 := A and (B xor C)} check('bit_blt6'); gpr_$set_raster_op(0,gpr_$rop_src_or_dst,status); gpr_$bit_blt(temp,source,0,dest,0,status); {three1 := (A and (B xor C)) or (B and C)} check('bit_blt7'); gpr_$set_bitmap(three0,status); gpr_$set_raster_op(0,gpr_$rop_src_xor_dst,status); gpr_$bit_blt(bitmap,source,0,dest,0,status); {three0 := B xor C xor A} check('from'); release; gpr_$set_bitmap(sum0,status); gpr_$set_raster_op(0,gpr_$rop_src,status); gpr_$bit_blt(three0,sourceup,0,dest,0,status); {sum0 := three0U} check('bit_blt8'); gpr_$set_raster_op(0,gpr_$rop_src_xor_dst,status); gpr_$bit_blt(three0,source,0,destdown,0,status); {sum0 := three0U xor three0D} check('bit_blt9'); gpr_$set_bitmap(temp,status); gpr_$set_raster_op(0,gpr_$rop_src,status); gpr_$bit_blt(three0,sourceup,0,dest,0,status); {temp := three0U} check('bit_blt10'); gpr_$set_raster_op(0,gpr_$rop_src_and_dst,status); gpr_$bit_blt(three0,source,0,destdown,0,status); {temp := three0U and three0D} check('bit_blt11'); gpr_$set_bitmap(carry,status); gpr_$set_raster_op(0,gpr_$rop_src,status); gpr_$bit_blt(three0,source,0,dest,0,status); {carry := three0} check('bit_blt12'); gpr_$set_raster_op(0,gpr_$rop_src_and_dst,status); gpr_$bit_blt(sum0,source,0,dest,0,status); {carry := three0 and (three0U xor three0D)} check('bit_blt13'); gpr_$set_raster_op(0,gpr_$rop_src_or_dst,status); gpr_$bit_blt(temp,source,0,dest,0,status); {carry := (three0 and (three0U xor three0D)) or (three0U and three0D)} check('bit_blt14'); gpr_$set_bitmap(sum0,status); gpr_$set_raster_op(0,gpr_$rop_src_xor_dst,status); gpr_$bit_blt(three0,source,0,dest,0,status); {three0 := three0U xor three0D xor three0} check('bit_blt15'); gpr_$set_bitmap(sum1,status); gpr_$set_raster_op(0,gpr_$rop_src,status); gpr_$bit_blt(carry,source,0,dest,0,status); {sum1 := carry} check('bit_blt16'); gpr_$set_raster_op(0,gpr_$rop_src_xor_dst,status); gpr_$bit_blt(three1,source,0,dest,0,status); {sum1 := carry xor three1} check('bit_blt17'); gpr_$set_bitmap(temp,status); gpr_$set_raster_op(0,gpr_$rop_src,status); gpr_$bit_blt(three1,sourceup,0,dest,0,status); {temp := three1U} check('bit_blt18'); gpr_$set_raster_op(0,gpr_$rop_src_xor_dst,status); gpr_$bit_blt(three1,source,0,destdown,0,status); {temp := three1U xor three1D} check('bit_blt19'); gpr_$set_bitmap(sum2,status); gpr_$set_raster_op(0,gpr_$rop_src,status); gpr_$bit_blt(temp,source,0,dest,0,status); {sum2 := three1U xor three1D} check('bit_blt20'); gpr_$set_raster_op(0,gpr_$rop_src_and_dst,status); gpr_$bit_blt(sum1,source,0,dest,0,status); {sum2 := (three1U xor three1D) and (carry xor three1)} check('bit_blt21'); gpr_$set_bitmap(sum1,status); gpr_$set_raster_op(0,gpr_$rop_src_xor_dst,status); gpr_$bit_blt(temp,source,0,dest,0,status); {sum1 := carry xor three1 xor three1U xor three1D} check('bit_blt22'); gpr_$set_bitmap(temp,status); gpr_$set_raster_op(0,gpr_$rop_src,status); gpr_$bit_blt(three1,sourceup,0,dest,0,status); {temp := three1U} check('bit_blt23'); gpr_$set_raster_op(0,gpr_$rop_src_and_dst,status); gpr_$bit_blt(three1,source,0,destdown,0,status); {temp := three1U and three1D} check('bit_blt24'); gpr_$set_bitmap(sum2,status); gpr_$set_raster_op(0,gpr_$rop_src_xor_dst,status); gpr_$bit_blt(temp,source,0,dest,0,status); {sum2 := ((three1U xor three1D) and (carry xor three1)) xor (three1U and three1D)} check('bit_blt25'); gpr_$set_bitmap(temp,status); gpr_$set_raster_op(0,gpr_$rop_src,status); gpr_$bit_blt(carry,source,0,dest,0,status); {temp := carry} check('bit_blt26'); gpr_$set_raster_op(0,gpr_$rop_src_and_dst,status); gpr_$bit_blt(three1,source,0,dest,0,status); {temp := carry and three1} check('bit_blt27'); gpr_$set_bitmap(sum2,status); gpr_$set_raster_op(0,gpr_$rop_src_xor_dst,status); gpr_$bit_blt(temp,source,0,dest,0,status); {sum2 := ((three1U xor three1D) and (carry xor three1)) xor (three1U and three1D) xor (carry and three1D)} check('bit_blt28'); {Right! we've now counted the neighbours of a cell. a cell is alive in the next generation if it has exactly 3 neighbours or if it has exactly four neighbours and is alive now i.e bitmap := (sum0 and sum1 and not sum2) or (bitmap and sum2 and not sum1 and not sum1)} gpr_$set_bitmap(temp,status); gpr_$set_raster_op(0,gpr_$rop_src,status); {this is the default but set it anyway} gpr_$bit_blt(sum0,source,0,dest,0,status); {temp := sum0} check('bit_blt29'); gpr_$set_raster_op(0,gpr_$rop_src_and_dst,status); gpr_$bit_blt(sum1,source,0,dest,0,status); {temp := sum0 and sum1} check('bit_blt30'); gpr_$set_raster_op(0,gpr_$rop_not_src_and_dst,status); gpr_$bit_blt(sum2,source,0,dest,0,status); {temp := sum0 and sum1 and not sum2} check('bit_blt31'); acquire; gpr_$set_bitmap(bitmap,status); gpr_$set_raster_op(0,gpr_$rop_src_and_dst,status); gpr_$bit_blt(sum2,source,0,dest,0,status); {bitmap := bitmap and sum2} check('bit_blt32'); gpr_$set_raster_op(0,gpr_$rop_not_src_and_dst,status); gpr_$bit_blt(sum0,source,0,dest,0,status); {bitmap := bitmap and sum2 and not sum0} check('bit_blt33'); gpr_$bit_blt(sum1,source,0,dest,0,status); {bitmap := bitmap and sum2 and not sum0 and not sum1} check('bit_blt34'); gpr_$set_raster_op(0,gpr_$rop_src_or_dst,status); gpr_$bit_blt(temp,source,0,dest,0,status); {bitmap := (bitmap and sum2 and not sum0 and not sum1) or (sum0 and sum1 and not sum2)} check('bit_blt35'); release; acquire; discard(gpr_$cond_event_wait( event_type, event_data, pos, status )); until event_type=gpr_$keystroke; end; procedure read_bitmap(display_bitmap: gpr_$bitmap_desc_t; IN bitmap_name:file_name_type); {copy the bitmap stored in file_name to the screen (display_bitmap)} var window : gpr_$window_t; {specifies origin and size of rectangular region of bitmap to copied from (to)} dest : static gpr_$position_t := [0,0]; {destinition point for our bit-blts will always be (0,0)} file_size : gpr_$offset_t; file_bitmap : gpr_$bitmap_desc_t; version : gpr_$version_t; {some useless information returned by gpr_$open_bitmap_file} groups : integer; {more of the same} group_hs : gpr_$bmf_group_header_array_t; {field pixel_size * field n_sects should give # of planes in bitmap} created : boolean; {tells us if the bitmap file was created - should be false} attribs : gpr_$attribute_desc_t; {the attribute block for the bitmap file} wpl,bpi : integer; stream : stream_$id_t; type bit_row = array[1..gpr_$max_x_size div 8] of char; gmf_header = record {WARNING these definition was found by looking in a gmf file} unknown1,unknown2:integer; {these both seem to be one always} x_size,y_size:integer; {dimensions of bitmap} dpi:integer; {dots per inch of bitmap} end; var plane_ptr : ^bit_row; data_ptr : ^gmf_header; begin gpr_$allocate_attribute_block( attribs, status ); {our window} gpr_$open_bitmap_file( gpr_$readonly, bitmap_name.body, bitmap_name.length, version, {open the bitmap file} file_size, groups, group_hs, attribs, file_bitmap, created, status ); if status.all <> status_$ok then begin gmf_$open(bitmap_name.body,bitmap_name.length,gmf_$read,stream,status); if status.all <> status_$ok then begin writeln('Couldn''t open ',bitmap_name); error_$print(status); pgm_$exit; end; {if} discard(ios_$locate(stream,[ios_$preview_opt],data_ptr,sizeof(gmf_header),status)); check('ios_locate'); file_size.x_size := data_ptr^.x_size; file_size.y_size := data_ptr^.y_size; gpr_$allocate_bitmap(file_size,0,attribs,file_bitmap,status); gpr_$inq_bitmap_pointer(file_bitmap,plane_ptr,wpl,status); check('inq bmap ptr'); gmf_$restore_plane(stream,data_ptr^.x_size,data_ptr^.y_size,wpl,plane_ptr,bpi,status); check('restore'); gmf_$close(stream,status); gpr_$set_raster_op(0,gpr_$rop_not_src,status); {flip bits on copy} end;{if} acquire; gpr_$set_bitmap( display_bitmap, status ); window.window_base := dest; {we plan to bit_blt the whole} window.window_size := file_size; {bitmap file} gpr_$pixel_blt( file_bitmap, window, dest, status ); check('pixel_blt'); {does a bit_blt from bitmap file to display} gpr_$deallocate_bitmap(file_bitmap,status); gpr_$deallocate_attribute_block(attribs,status); end; {read_bitmap} BEGIN pgm_$get_args(no_of_args,arg_pointer); {find out how bitmap files we have to display} if no_of_args = 1 then begin append(dm_copy_image,bitmap_name); pad_$dm_cmd(stream_$stdout,dm_copy_image.body,dm_copy_image.length,status); check('dm command'); end else begin bitmap_name.length := pgm_$get_arg( 1, bitmap_name.body, status, sizeof(bitmap_name.body)); {get the name of the file} if bitmap_name.body[1] = '-' then begin if bitmap_name.body[2] in ['b','B'] then begin if no_of_args = 2 then begin mode := gpr_$borrow_nc end else begin mode := gpr_$borrow; bitmap_name.length := pgm_$get_arg( 2, bitmap_name.body, status, sizeof(bitmap_name.body)); {get the name of the file} end;{if} end else begin writeln('Usage: life [-b[orrow]] [bitmap_name]'); pgm_$exit; end; {if} end; {if} end; {if} gpr_$init( mode, stream_$stdout, display_size, display_hi_plane, display_bitmap, status ); {initialises graphics package} check('init'); gpr_$inq_bitmap_dimensions( display_bitmap, display_size, display_hi_plane, status ); {find out how big our window is} gpr_$set_obscured_opt( gpr_$block_if_obs, status ); {if we try to draw in our window and it is covered - pop the window} gpr_$set_auto_refresh(true,status); gpr_$set_clipping_active(true,status); if mode <> gpr_$borrow_nc then read_bitmap(display_bitmap,bitmap_name); if no_of_args = 1 then name_$delete_file(bitmap_name.body,bitmap_name.length,status); life_bitmap(display_bitmap); release; gpr_$terminate( true, status ); {all done} END. From apollo-request@umix.cc.umich.edu Wed Aug 2 21:26:04 1989 Date: 2 Aug 89 17:02:29 GMT From: lau%kings.wharton.upenn.edu%netnews.upenn.edu.uucp@rutgers.edu (Yan K. Lau) Organization: Otto's Bay Subject: question about path setup under sr10.1/bsd4.3 Message-Id: <13400@netnews.upenn.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu How does one change the default path of users when they log into a node or create a shell under SR10.1/BSD4.3? We have both Aegis and Unix running. Some users use the C shell or Bourne shell and others use the Aegis shell. I want to be able to add to the default path. Apollo has added /usr/apollo/bin in the path. I want the csh or sh users to be able to find commands in the /com directory and the Aegis users to get to the ftp and telnet commands. There may be other directories which should be in the path. Instead of individually changing the user startup scripts, is there a way to set these things for all users? Yan. --- Yan K. Lau + the last message of a newgroup will be: )~ + a) longer than one screen & ~/~ lau@scrolls.wharton.upenn.edu + b) something you're not interested in. /\ University of Pennsylvania + your decision, 'n' key or space bar? From apollo-request@umix.cc.umich.edu Wed Aug 2 23:26:05 1989 Date: 2 Aug 89 22:01:50 GMT From: lori%hacgate%usc.uucp@rutgers.edu (Lori Barfield) Organization: Hughes Aircraft Co., El Segundo, CA Subject: Re: domain protocol over twisted pair Message-Id: <4537@hacgate.scg.hac.com> References: <8908012221.AA05657@richter.mit.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Well, here in my group this discussion went around awhile ago. We have an internet of two rings, and the communication between the two was at times 100 times slower than normal inter-ring talk. One engineer ran tests on our DN3000 on SR9.7; he claims that the Suns on the *same* Ethernet are much, much faster than the Apollo is. When I sent him a copy of David's post, this is what he replied: >In article <8908012221.AA05657@richter.mit.edu> krowitz@RICHTER.MIT.EDU (David Krowitz) writes: > >[...]telecom office states that the maximum throughput of an ethernet > > segment is 3 MB/sec on a 10 Mhz thick ethernet cable. This is due > > to packet collisions eating up network bandwith. Thus, the maximum > >[...] >On our network we typically run at less than %10 of ethernet capacity >according to our network monitoring tools. Collissions are VERY rare >events, I estimate I see a collision once every 10 minutes. You can >see this by bringing up the performence meter and selecting the >collisions or by looking at one of the ethernet transceivers with >the LED lights on it. > >Also I used to run 10-12 diskless suns on an ethernet, doing all >their swapping and paging over ethernet and never used more than >%20 of ethernet capacity. I suspect the Apollo interface to >ethernet is just plain Lame. So the problem apparently isn't collision. Any comments? Is SR10 any better for Native? ...lori From apollo-request@umix.cc.umich.edu Thu Aug 3 19:26:19 1989 Date: 3 Aug 89 22:24:58 GMT From: cynthia@cod.nosc.mil (Cynthia G. Anderson) Organization: Naval Ocean Systems Center, San Diego Subject: Apollo Serial IO line problems (HELP!) Message-Id: <1594@cod.NOSC.MIL> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu help! i hope there is an Apollo-Guru-In-Chief out there somewhere. for the last few months, i have been battling with an sio line problem on my apollo DN3010. Basically, it doesn't work. I've come full circle and once again believe it is a software problem not hardware. First, some background: this is a stand alone Apollo DN 3010(8M RAM, 380M disk, CT drive, 19" color monitor, ethernet card) it does NOT have maintainence my supervisor doesn't want to pay for a service call and considers the machine a white elephant, so i'm all alone out here--so to speak. i have talked briefly with apollo a few times, but even tho they try and help over the phone i can tell they'd really rather not judge the problem without physically seeing the machine...and since i don't have maintainence on it, i don't want to try their patience with too many calls. i have run CPU.DEX on it--with and without a loopback connector-- both ways (internal and external logic) came up perfectly fine. this machine has X windows running on it (X11.r2)--and i have turned it off and tried to get the sio line to work. As well as turning off TCP/IP. (this includes rebooting without them.) the machine has crashed a number of times--and i have had to load up Aegis 9.7_1 into it instead of it's original 9.7_2 (since apollo never sent me the source for Aegis when i purchased the machine.) I don't know if this is significant or not. I've tried using emt, (terminal emulation) as well as kermit. These same programs with identical configurations work on other apollo's around here. Likewise, i've checked the cables and the modems--they're ok. emt worked originally when i got the machine 2 years ago, but not now. Hopefully significant: the error i get whenever i use emt now is Unable to open stream to SIO line: /dev/sio1 --cannot open a remote sio line (stream manager/open) Funny THing I noticed: i can run kermit from within X (sort of)--apparently it isn't seen to be in local mode (because it tells me so when i try to connect! "Connect only works in Local Mode") but it does seem to make some sort of connection within itself. i don't know. Anyway, that's the problem. I'm at my physical end with this problem. I dearly hope someone out there has seen this problem before. thank you cynthia anderson [knowledgable suggestions only please--no snide comments about apollos or my machine...i get enuff of that from my supervisor.] -- cynthia anderson Naval Ocean Systems Center, San Diego, CA 92107 cynthia@cod.nosc.mil Disclaimer: "Ronnie made me do it!" From apollo-request@umix.cc.umich.edu Thu Aug 3 21:22:38 1989 Date: 3 Aug 89 20:11:00 GMT From: nazgul%apollo%ulowell%mailrus.uucp@ames.arc.nasa.gov (Kee Hinckley) Organization: Apollo Computer, Chelmsford, MA Subject: Re: question about path setup under sr10.1/bsd4.3 Message-Id: <44d047e0.1b147@apollo.HP.COM> References: <13400@netnews.upenn.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <13400@netnews.upenn.edu> lau@kings.wharton.upenn.edu (Yan K. Lau) writes: >How does one change the default path of users when they log >into a node or create a shell under SR10.1/BSD4.3? >We have both Aegis and Unix running. Some users use the >C shell or Bourne shell and others use the Aegis shell. In the Bourne and Korn shells you can do it by changing /etc/profile and /etc/profile.ksh. Neither the C shell or the Com shell have means of doing this, however with the Com shell you could try (I don't guarantee this though since at login the shell might ignore it) setting the environment variable "CSR" in the DM login scripts. Otherwise the best way is to simply install a default .login or $HOME/user_data/sh/login script for every user. -kee -- ### User Environment, Apollo Computer Inc. ### Public Access ProLine BBS ### ### {mit-eddie,yale}!apollo!nazgul ### nazgul@pro-angmar.cts.com ### ### nazgul@apollo.com ### (617) 641-3722 300/1200/2400 ### I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. From apollo-request@umix.cc.umich.edu Fri Aug 4 15:28:33 1989 Date: 4 Aug 89 02:37:40 GMT From: brigman%stdc01%rti.uucp@mcnc.org (James Brigman) Organization: Star Technologies, Graphicon Products Division (RTP, N.C) Subject: Misc. Apollo Stuff for sale Message-Id: <515@stdc01.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Items for Sale: about 100' of Domain token ring coax cable: $40.00 3 BNC-TO-DSUB network connection cables, Part # 007605. Retail for $100 each from Apollo. Will sell for $50 each or all three for $125. 10 large 3-ring Apollo binders of documentation, such as: domain C language reference Domain System Call Reference Sys Admin for Domain/IX BSD4.2 Domain Binder and Librarian Reference Domain/IX System Call Reference And may more titles....circa 1986. Will give these to a good home for the cost of shipping. Call James Brigman at (919) 832-9086 between 8am-9pm EDT. From apollo-request@umix.cc.umich.edu Fri Aug 4 15:29:35 1989 Message-Id: <8908041741.AA11143@umix.cc.umich.edu> Date: Fri, 4 Aug 89 13:03 EDT From: FERGUSON%TMASL.EXXON.COM@CUNYVM.CUNY.EDU Subject: RE: Serial IO Line Problem To: apollo@umix.cc.umich.edu X-Vms-To: APOLLO Possibly your serial problem is that the SIO device files in the /dev directory are screwed up, or not compatible because of the regression in Aegis from 9.7.2 to 9.7.1, I don't know whether that would effect the situation or not. Anyway, if you can get 9.7.1 `node_data/dev sio files from a release tape, or from another machine at your site, try replacing the existing ones with another version. Or, just list different copies of the /dev/sio* files and see if they have the same number of bytes, that's usually a good way to compare files. Good Luck Scott Ferguson Exxon Research & Engineering Annandale, NJ 08801 (201) 730-2339 ferguson@erevax.bitnet From apollo-request@umix.cc.umich.edu Sat Aug 5 21:25:37 1989 Date: 5 Aug 89 05:00:00 GMT From: tim%hi-csc.uucp@uunet.uu.net (Tim Giebelhaus) Organization: mpls Subject: Re: domain protocol over twisted pair Message-Id: <609@apcimsp.UUCP> References: <13604@bcsaic.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <13604@bcsaic.UUCP> vince@bcsaic.UUCP (Vince Skahan) writes: >Does anyone have any information about any of the following ? > - should we see definite slowness between rings regardless of >how the rings are connected to ethernet ? we remember a definite >perceived slowness of "native apollo" relative to the old "etherbridge" >product. Of course any gateway is going to slow down the data. If the gateway is busy doing something else, or is asked to gateway more data than it can handle, the tcp, routed, and other supporting processes will not get the data through very quickly. > - should we see a special drop in performance over Latticenet >(is anyone using Apollo over laticcenet. ?)? I'm not sure what Latticenet is. If it does not work at a speed of 10 mb/s they you are very likely to have problems. The time outs and such on Apollos are written with the assumption that you are running raw data of 10 mb/s. > - if Latticenet is "real ethernet" why isn't it officially >supported? We need good technical reasons to make the networking folks >take notice. If Latticenet is "real ethernet" and follows the 802.3 specs to the letter, then it should not be a problem. > - should we see any difference in performance from node to node >if the nodes are on Latticenet relative to them being on drop cables Only if Latticnet is not reliably forwarding the packets or is not forwarding the packets as fast as "real eithernet". > - should we see perceptable (real perceptable) slowness going >over ethern to copy files, do backups, copy large trees with lots of >small files, etc. ? You point out small file in particular. Of course the opening of lots of files is going to take longer than opening one file and then copying the same amount of data. Also, I sure you understand heavy use such as backups is bound to slow up the network and the node. > - what is the REAL minimum speed of the ethernet to enable >reasonable apollo-apollo communications without experiencing network >timeouts ? We have one bulding remotely located with a link that is >about 1/2 of T-1 speed. We experience lots of network timeouts between >down there and the rest of the ethernet. When you consider that we have >a registry site down there, it takes forever to add accounts, change >passwords, etc. Apollo states in it's manuals that you must use at least a T-1 phone line if you are using phone lines. I know of sites which use 56kb, but this is not supported and problems are seen with it. I would recommend a less robust protocol for slower speeds such as NFS. If you have 9.7 registries then you indeed will take a while to do registry operations as, up till sr10, the entire registry was copied over and then copied back. I would recommend the reading of all the SR10 networking manuals. Especially the planning manual may be useful. -- UUCP: uunet!hi-csc!apcimsp!tim ARPA: tim@apollo.com Contents of this message has nothing to do with work. From apollo-request@umix.cc.umich.edu Sun Aug 6 07:23:28 1989 Date: 4 Aug 89 21:09:26 GMT From: dclemans%mntgfx%sequent%tektronix.uucp@beaver.cs.washington.edu (Dave Clemans @ APD x1292) Organization: engr Subject: Re: GNU CC on Apollo 10.1? Message-Id: <1989Aug4.210926.2263@mentor.com> References: <26119@shemp.CS.UCLA.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >From article <26119@shemp.CS.UCLA.EDU>, by taylor@lanai.cs.ucla.edu (Charles Taylor): > > I got the recently posted kit of programs needed to run GNU CC > on an Apollo under SR 10.1. > > I'm right now in the middle of building it, and I'd like to know one > thing before I go on: > > Do I need to port and compile the GNU assembler (gas) as well in order > to run GNU CC? > > If anybody's successfully gotten GNU CC to work, I'd appreciate it if > you'd drop me a note and tell me what you had to do... > > Thanks, > Matt Kennel > kennel@cognet.ucla.edu Presuming that you are talking about my gnu->coff converter, yes you do have to compile gas; the output of gas is what the converter operates on. dgc From apollo-request@umix.cc.umich.edu Sun Aug 6 09:19:26 1989 Date: 4 Aug 89 14:24:24 GMT From: has%ztivax%unido%mcvax.uucp@uunet.uu.net (Hans-Albert Schneider) Organization: Siemens AG in Munich, W-Germany Subject: Re: How can I get the Ethernet No. of an Apollo Message-Id: <716@ztivax.UUCP> References: <507@cadlab.cadlab.de>, <349@simon.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <349@simon.UUCP> root@simon.UUCP (Local Deity) writes: >In article <507@cadlab.cadlab.de>, schmidt@cadlab.uucp (Michael Schmidt) writes: >> We have 3com Ethernet boards in one of our Apollos. Can any kind >> soul tell me, how I can get the Ethernet No. of one of these boards? >> -- > ... >If the system is up and running you can find out the Ethernet address by using >the arp command available under UNIX. where is this command located under SR9.7? (Or is it unavailable until SR10?) I did not find it in the /bsd4.2 tree. Hans-Albert -- Hans-Albert Schneider ARPA: has@ztivax.siemens.com Siemens AG, ZFE F 2 INF 21 or: has%ztivax@siemens.siemens.com Otto-Hahn-Ring 6, Munich, W.Germany UUCP: ...!uunet!mcvax!unido!ztivax!has phone: (+49) 89 636 45 890 EUnet: has@ztivax.UUCP From apollo-request@umix.cc.umich.edu Mon Aug 7 15:28:53 1989 Date: 7 Aug 89 16:30:27 GMT From: cynthia@cod.nosc.mil (Cynthia G. Anderson) Organization: Naval Ocean Systems Center, San Diego Subject: RE: Apollo serial I/O port problems -- thanks! Message-Id: <1596@cod.NOSC.MIL> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Thank you to all you sent me advice and help on my problems with my SIO port. Turns out the links were messed up. So at least I can utilize Kermit again, even if some of the specialized programs we have still don't work thru the port. thanks again, cynthia anderson -- cynthia anderson Naval Ocean Systems Center, San Diego, CA 92107 cynthia@cod.nosc.mil Disclaimer: "Ronnie made me do it!" From apollo-request@umix.cc.umich.edu Mon Aug 7 21:21:24 1989 Date: 7 Aug 89 16:57:45 GMT From: roode%hydra.cf.uci.edu%orion.cf.uci.edu%uci-ics.uucp@cs.ucla.edu (Dana Roode) Organization: University of California, Irvine Subject: lp spooling with lpd under 10.1 Message-Id: <2474@orion.cf.uci.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am about to attempt hooking up a serial line printer to one of the serial ports on a DN3500 and spool to it. Being more of a UNIX type than an Apollo type, my inclination is to do lp spooling with lpd. I remember being cautioned against this by a salesman - is there some problem with using lpd under 10.1? Dana Roode UCIrvine Academic Computing From apollo-request@umix.cc.umich.edu Tue Aug 8 09:33:39 1989 Date: Tue, 8 Aug 89 08:48:38 EDT From: crh@apollo.eng.ohio-state.edu (Charlotte Hawley) Message-Id: <8908081248.AA01247@apollo.eng.ohio-state.edu> To: apollo@umix.cc.umich.edu, roode%hydra.cf.uci.edu%orion.cf.uci.edu%uci-ics.uucp@cs.ucla.edu Subject: Re: lp spooling with lpd under 10.1 I am using lpd with no problems. If you are just printing from this one DN3500, just set your printer up with your UNIX knowledge. It gets a little tricky when setting up lpd in a network. I got some help from Apollo, and everything works fine. If you want specifics, feel free to give me a call. (614) 292-2902. Charlotte Hawley From apollo-request@umix.cc.umich.edu Tue Aug 8 09:37:26 1989 Message-Id: <8908081257.AA03206@umix.cc.umich.edu> Date: Tue, 8 Aug 89 08:53 EDT From: FERGUSON%TMASL.EXXON.COM@CUNYVM.CUNY.EDU Subject: GPR->XWD Bitmap conversion To: apollo@umix.cc.umich.edu X-Vms-To: APOLLO I haven't received my X11R3 from Apollo yet, but I thought I'd ask this anyway. Is there a conversion program in or out of X-Apollo for changing GPR bitmaps into XWD (X-Window Dump) format? Obviously, you could grab the picture off the screen, but a way to do it without using the display would be nice for printing to remote printers that don't know what a GPR bitmap is. Thanks, Scott Ferguson Exxon Research & Engineering Annandale, NJ 08801 (201) 730-2339 ferguson@erevax.bitnet From apollo-request@umix.cc.umich.edu Tue Aug 8 15:36:38 1989 Date: 8 Aug 89 15:18:42 GMT From: sakas%mcvax.uucp@uunet.uu.net (Vassilis Sakas) Organization: CWI, Amsterdam Subject: Re: security bug Message-Id: <8322@boring.cwi.nl> References: <108@tugiaik.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <108@tugiaik.UUCP> plipp@tugiaik.UUCP (Peter Lipp) writes: > >__________________________________________________________________ > >Possible Security Problem with DOMAIN-OS and the Display-Manager >__________________________________________________________________ > > LINES DELETED > Usually, security bugs don't have to be announced SO open in the net. Your student didn't misuse this programm, but imagine how many other persons are now able to do it after your posting. Please be more carefull the next time. Waiting for the bug fix, Vassilis Sakas, A part-time system administrator on Apollos. E-mail: sakas@zgdvda.uucp From apollo-request@umix.cc.umich.edu Tue Aug 8 15:37:24 1989 Date: 8 Aug 89 16:14:05 GMT From: dkukral%encad%ncrwic%ncrlnk.uucp@uunet.uu.net (Dean Kukral) Organization: NCR Corporation Wichita, KS Subject: Correction to Apollo insert file pgm.ins.c Message-Id: <757@encad.Wichita.NCR.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I believe that line 40 of /sys/ins/pgm.ins.c should be changed from typedef int *pgm.$argv[128] to typedef *pgm *pgm.$argv[128] This change will only affect those C programmers who are using the PGM system calls such as pgm_$invoke. From apollo-request@umix.cc.umich.edu Wed Aug 9 01:22:34 1989 Date: 8 Aug 89 22:10:00 GMT From: dawson%apollo.uucp@eddie.mit.edu (Keith Dawson) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: security hole Message-Id: <44e9d7d4.c4b0@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In a recent posting Peter Lipp [plipp@tugiig.uucp] details a > Possible Security Problem with DOMAIN-OS and the Display-Manager This security problem has been fixed in SR10.2. Patches have been generated for earlier releases: SR9.7 -- patch # 184 on the June 1989 patch tape SR10.1 -- patch # m0048 on the August 1989 tape These patches can be applied to /lib/streams on any version of SR9.7 and SR10.1, including the versions that support Domain/X11. Please see your local support office to obtain copies of these patch tapes. We regret the broad dissemination of detailed instructions for exploiting a security hole. ____________________________________________________________ Keith Dawson Section Manager, Window Systems Group Hewlett Packard Co. 508-256-0176 x5739 Graphics Technology Division / East 300 Apollo Dr. (CHR.03.DE) Chelmsford, MA 01824 USA Internet: dawson@apollo.hp.com UUCP: {mit-eddie,yale,uw-beaver}!apollo!dawson From apollo-request@umix.cc.umich.edu Wed Aug 9 09:22:56 1989 Date: 9 Aug 89 11:09:58 GMT From: plipp%tugiaik%tuvie%mcvax.uucp@uunet.uu.net (Peter Lipp) Organization: none Subject: Re: security bug Message-Id: <109@tugiaik.UUCP> References: <108@tugiaik.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <108@tugiaik.UUCP>, plipp@tugiaik.UUCP (Peter Lipp) writes: > > Possible Security Problem with DOMAIN-OS and the Display-Manager > Keith Dawson of Apollo/Hp writes in another article: > We regret the broad dissemination of detailed instructions for exploiting > a security hole. I answered him as follows: > I personally do not think and hope that my posting will do considerable harm. My opinion is that > the best way to prevent the misuse of such holes is to publish them so that everybody > is aware of the problem. I now there might occur situations where the wrong people might > become aware and the right people might not. > > I think there might be lots of users out there not going to change to 10.2 and not knowing and > getting the patches automatically. And there might be other smart students or users who > find out about this possibility and misuse it. This I consider the worse case. > > Furtheron you might have informed at least local representatives to enable them to > answer my inquiries about a month ago. If they had known about the problem, I surely would > not have posted that stuff. > I would like to hear from you what you think about this - do you prefer to know about existing security bugs or do you prefer not to be aware of. There is an easy but tedious way to prevent this until the August 1989 patch tape is available (here, in Austria, in September): Just type in a wrong password. This should do for a while. Then check if your keyboard has been redefined and change your password immediately. Are there any better suggestions out there? I truely hope not having caused troubles somewhere, which I would regret. Please post your reactions - and send a copy by email to me directly. Peter Peter Lipp - Institute for Applied Information Processing University of Technology, Graz, Austria plipp@tugiig.uucp - plipp@tugiig.at - mcvax!tuvie!tugiig!plipp -- Peter Lipp - Institute for Applied Information Processing University of Technology, Graz, Austria plipp@tugiig.uucp - plipp@tugiig.at - mcvax!tuvie!tugiig!plipp From apollo-request@umix.cc.umich.edu Wed Aug 9 13:23:55 1989 From: frank@caen.engin.umich.edu (Randy Frank) Message-Id: <44edb1250.001b7ec@caen.engin.umich.edu> To: plipp%tugiaik%tuvie%mcvax.uucp@uunet.uu.net Cc: apollo@umix.cc.umich.edu Subject: Re: security bug In-Reply-To: Your message of 09 Aug 89 11:09:58 GMT. <109@tugiaik.UUCP> Date: Wed, 09 Aug 89 12:32:20 -0400 I have mixed feeling about the publishing of security holes; it certainly can make life difficult for those with vulnerable systems until patches are found. However, it also causes patches to be found a lot faster! In the case of Apollo we have regularly complained that way too much Apollo security is "security through obscurity" as opposed to enforced security in the kernel. (The fact that the patches proposed are being made to libraries instead of the kernel leads me to believe that the underlying hole is still there, just made more difficult, i.e., obscure, to exploit.) The fact that Apollo often relies on unpublished interfaces as a way of providing "security" is simply not acceptable. While the standard Unix kernel is by no means fully secure, at least there are no known cases where something is considered secure simply because a hole is unpublished. Apollo needs to provide security that's at least as good as "standard" Unix, which means at a minimum means not viewing unpublished interfaces as secure. Randy Frank From apollo-request@umix.cc.umich.edu Wed Aug 9 15:19:54 1989 Date: 9 Aug 89 01:11:58 GMT From: steve%simon%obdient%laidbak%att.uucp@ucbvax.Berkeley.EDU (Steven E. Piette) Organization: ACT, Inc., Dank Dark Cave, Algonquin, IL. Subject: Re: Apollo Serial IO line problems (HELP!) Message-Id: <353@simon.UUCP> References: <1594@cod.NOSC.MIL> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1594@cod.NOSC.MIL>, cynthia@cod.NOSC.MIL (Cynthia G. Anderson) writes: > help! > > i have run CPU.DEX on it--with and without a loopback connector-- > both ways (internal and external logic) came up perfectly fine. >From to sounds of it the port is working, but .... > > I've tried using emt, (terminal emulation) as well as kermit. > These same programs with identical configurations work on > other apollo's around here. > > Hopefully significant: > the error i get whenever i use emt now is > Unable to open stream to SIO line: /dev/sio1 --cannot open a remote sio > line (stream manager/open) What we need now is an ld -a of the /sys/node_data/dev directory. It sounds like the entry for sio1 is something other than a file of type sio. Given the problems you had with software and system crashes this could be wrong. The files for the sio ports in the dev directory ARE special. They have a type of sio and contain information on which port they are for. (I never tried to find out where. Maybe it was via a canned ACL in the VTOCE that gave the port.) Anyway, let's see what the dev directory looks like since the error message looks like /dev/sio1 (really /dev -> `node_data/dev) is linked or pointing to another system and so the remote part of the message. I hope this helps. > > cynthia anderson > Naval Ocean Systems Center, San Diego, CA 92107 -- Steven E. Piette Applied Computer Technology Inc. UUCP: {smarthost}!simon!steve 1750 Riverwood Drive INET: steve@simon.CHI.IL.US or spiette@SUN.COM Algonquin, IL 60102 ------------------------------------------------------------------------------- From apollo-request@umix.cc.umich.edu Wed Aug 9 15:27:18 1989 Date: 9 Aug 89 02:23:41 GMT From: steve%simon%obdient%laidbak%att.uucp@ucbvax.Berkeley.EDU (Steven E. Piette) Organization: ACT, Inc., Dank Dark Cave, Algonquin, IL. Subject: Re: How can I get the Ethernet No. of an Apollo Message-Id: <354@simon.UUCP> References: <507@cadlab.cadlab.de>, <349@simon.UUCP>, <716@ztivax.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <716@ztivax.UUCP>, has@ztivax.UUCP (Hans-Albert Schneider) writes: > In article <349@simon.UUCP> steve@simon.UUCP (Steve Piette) writes: > >In article <507@cadlab.cadlab.de>, schmidt@cadlab.uucp (Michael Schmidt) writes: > >> We have 3com Ethernet boards in one of our Apollos. Can any kind > >> soul tell me, how I can get the Ethernet No. of one of these boards? > >> -- > > ... > >If the system is up and running you can find out the Ethernet address by using > >the arp command available under UNIX. > > where is this command located under SR9.7? (Or is it unavailable > until SR10?) I did not find it in the /bsd4.2 tree. > Yes I goofed up, the arp command doesn't seem to be under 9.7 it does exist in SR10. It may be a part of the tcp 3.x BSD stuff but I can't check it out. If it is included it should be in /etc (bsd4.2/etc). I know the BSD TCP 3.x release included ping and I thought arp as well but after a year the memory fades. (:-) But, I did remember another way to find out the ethernet address. When you start tcp_server give it a -d option. This will tell it to run in debug mode and the server will print the ethernet address of it's interface as a part of the startup in the window. I also belive the ether_diag program will print it, but not everyone has the ether_diag on their systems. (something about which release tape it was on) Anyway, I hope this is more helpful ( My apollo is still under water from the last time the basement flooded, so all I had to check with last time was my Sun) -- Steven E. Piette Applied Computer Technology Inc. UUCP: {smarthost}!simon!steve 1750 Riverwood Drive INET: steve@simon.CHI.IL.US or spiette@SUN.COM Algonquin, IL 60102 ------------------------------------------------------------------------------- From apollo-request@umix.cc.umich.edu Wed Aug 9 15:30:00 1989 Date: 9 Aug 89 15:43:00 GMT From: gaz%apollo.uucp@EDDIE.MIT.EDU (Gary Zaidenweber) Organization: Apollo Computer, Chelmsford, Mass. Subject: Re: Creating a window on a remote node Message-Id: <44ed8514.ce45@apollo.HP.COM> References: <492@calmasd.Prime.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >From article <492@calmasd.Prime.COM>, by sas@calmasd.Prime.COM (Shirley Sloper): > > Messages from long ago.... >> Someone writes: >>>From: "ANIMAL::THOMPSON" >>>Subject: Re: Placing a window on another node. >>> But. back to the question at hand. >>> [Great info on how to creat a pad on another node via send_alarm or >>> crp/crpad] >>> >>>John Thompson >> >>Either way (send_alarm, crp/crpad, /bin/write, or /bin/wall), you can't >> [blah, blah, blah.....] > > > Hello, > > Does anyone remember the above discussion? (I'm sorry the references > aren't there, this is all I can find.) I had just started reading the > group (June?) and I believe the main discussion may have been concerning > borrow mode. I'm not interested in borrow mode, what I would like is > the "great info on how to create a pad on another node...", that the > message refers to. Can someone inform me how to do this? > > This is the situation I am dealing with: A process on node A starts a > process (CPS) on node B. I want the node B process to be able to > inform node A that it is finishing, (either from a shell script or C > module). Most probably, the originating process on A is no longer > running. What I would like to do is create a window back on node A. > > Thankyou, thankyou, thankyou! > > > -- > Shirley A. Sloper sas@calmasd.prime.com > ****** Calma ****** > ** 9805 Scranton Road ** > ** San Diego, CA 92121 ** The following module sort of emulates the system() call, creating a window to run the shell. It runs under sr10.1+ (and maybe 10.0 I just haven't tried and don't expect to). I run in a sysV environment but I know this works in Aegis and BSD too. I believe that it will not run under sr9.7 without modifications.: #include #include #include #include void psystem(string) char *string; { pad_$window_desc_t window; status_$t st; char *path; ios_$id_t padin,padout,paderr; stream_$id_t strv[3]; short strc = 3; pgm_$mode mode; pgm_$proc phandle; int j; #define NARGC 3 struct arge nargv[NARGC]; pgm_$arg_ptr narg[NARGC]; short nargc = NARGC; name_$pname_t pstring; char *sh = "/bin/sh"; window.top = 0; window.left = 0; window.width = 0; window.height = 0; path = ""; pad_$create_window(path,0,pad_$transcript,(short)1,window,&padout,&st); if( st.all != status_$ok ) { error_$print(st); exit(-1); } else paderr = padout; pad_$create(path,0,pad_$input,padout,pad_$bottom,0,(short)20,&padin,&st); if( st.all != status_$ok ) { error_$print(st); exit(-1); } (VOID)strcpy(pstring,"sh -c "); (VOID)strcat(pstring,string); for(j=0;jchars,"sh"); narg[0]->len = (short)strlen(narg[0]->chars); strcpy(narg[1]->chars,"-c"); narg[1]->len = (short)strlen(narg[1]->chars); strcpy(narg[2]->chars,string); narg[2]->len = (short)strlen(narg[2]->chars); nargc = NARGC; strv[ios_$stdin] = padin; strv[ios_$stdout] = padout; strv[ios_$stderr] = paderr; mode = 0; /* run in "default" mode */ pgm_$invoke(sh,(short)strlen(sh),nargc,narg,strc,strv,mode,&phandle,&st); if( st.all != status_$ok ) { error_$print (st); exit(-1); } exit(0); } From apollo-request@umix.cc.umich.edu Wed Aug 9 15:31:30 1989 Date: 9 Aug 89 14:09:07 GMT From: collins%nvpna1%prles2%prle%phigate%hp4nl%mcvax.uucp@uunet.uu.net (Donal O'Coileain) Organization: Philips Research Labs (Nat Lab), Eindhoven, The Netherlands. Subject: Re: security bug Message-Id: <638@prles2.UUCP> References: <108@tugiaik.UUCP>, <109@tugiaik.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <109@tugiaik.UUCP> plipp@tugiaik.UUCP (Peter Lipp) writes: > I personally do not think and hope that my posting will do considerable harm. > the best way to prevent the misuse of such holes is to publish them so that > everybody is aware of the problem. By posting the source code you simply encouraged every user to try it. It would have been much more responsible of you to simply warn the net, leave Apollo have the source code and let them decide who was allowed to see it. > Furtheron you might have informed at least local representatives to enable > them to > answer my inquiries about a month ago. If they had known about the problem, > I surely would > not have posted that stuff. OUR local representatives WERE aware of the sr9.7 and pending sr10.1 patch. I say pending because we don't have the August sr10 tape yet in Holland. Donal O Coileain. collins@apolloway.prl.philips.nl or collins%nvpna1.prl.philips.nl@uunet.uu.nl -- And out of the gloom a voice said, 'Smile and be happy for things could be a lot worse'. So I smiled and was happy and behold, things got worse -- From apollo-request@umix.cc.umich.edu Wed Aug 9 15:36:37 1989 Date: 9 Aug 89 13:14:44 GMT From: pl%kuling%bmc1%draken%kth%mcvax.uucp@uunet.uu.net (Per Lindgren) Organization: Dept. of Computer Systems, Uppsala University, Sweden Subject: OS page size query Message-Id: <1124@kuling.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu OS page size query. I wonder if someone out there can explain the following for me. Background: This summer some students at our department prepared some computer architecture experiments on Apollo DN4000 workstations. The aim of one experiment was to find out the page size used (for VM paging). Method: They wrote a program that allocated a big array (4 Mb), and then a loop accessed elements in that array at certain intervals (the interval being the guessed page size). After the loop they compared the number of array references and the number of generated page faults (formed a ratio "page fault freq." / references made). Results: For interval sizes (or guessed page sizes) of less than 1024 bytes this ratio was less than 1.0, which makes sense. For a guessed page size of 1024 then ratio was ~1, and also for a guessed page size of 2048 bytes... But for guessed sizes over 2048 the ratio drops below 1.0 anew. Question: It makes sense that for a page size of 2048, the ratio should still be ~1.0, but why does it drop below 1.0 for bigger (guessed) page sizes? I would like the ratio to stay at 1.0! It is possible that I have missed something fundamental, but I can't figure out what. Please, if somenone can help me with an explanation I would be very happy. Please respond by e-mail, since I don't read this newsgroup regulary. Per Lindgren Dept. of Computer Systems Upsala University, Sweden E-mail: pl@mizar.docs.uu.se -- --Per Lindgren pl@kuling.UU.SE Dept. of Computer Systems or Uppsala University, SWEDEN pl%kuling.UU.SE@uunet.UU.NET From apollo-request@umix.cc.umich.edu Wed Aug 9 17:25:28 1989 Date: 9 Aug 89 16:41:23 GMT From: jim%eda.uucp@decwrl.dec.com (Jim Budler) Organization: EDA Systems, Inc. Santa Clara, CA Subject: Re: security hole Message-Id: <511@eda.com> References: <44e9d7d4.c4b0@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu dawson@apollo.HP.COM (Keith Dawson) writes: >This security problem has been fixed in SR10.2. Patches have been >generated for earlier releases: > SR9.7 -- patch # 184 on the June 1989 patch tape > SR10.1 -- patch # m0048 on the August 1989 tape >We regret the broad dissemination of detailed instructions for exploiting >a security hole. >____________________________________________________________ >Keith Dawson Section Manager, Window Systems Group > Hewlett Packard Co. 508-256-0176 x5739 > Graphics Technology Division / East We regret that it took such a blunt step to cause Apollo to bother to tell us that the hole exists, and has fixes. >From Sun Microsystems? Every quarter, a thick book arrives in the mail, detailing bug reports. Every month, a book arrives in the mail, containing interesting Technical details. I forget which usually contains notices of patches, perhaps both. >From Apollo? Every month, an invoice arrives. (Well, not any more 8^) ================ I fully agree with the posting of the bug. Look, INSTANT action. Explicit mention of compatibility of /lib/streams. High awareness in community of seriousness of bug. Report it to software support. You get told about the patch. Don't notice the problem. Remain ignorant. Post a note to Usenet less explicitely saying there is a bug. Response from Apollo may list patches, but people may not realize how serious it is, no matter how serious the poster says it is. Result: Hacker decides to explore area in question, finds hole, most people do not install patches, perhaps because of the confusion caused by the fact that almost everything Apollo fixes involves /lib/streams. The party line answer will be "what about all the people not on software support or Usenet" Apollo needs to solve that problem, not hide the facts from the rest of us.-- Jim Budler address = uucp: ...!{decwrl,uunet}!eda!jim domain: jim@eda.com voice = +1 408 986-9585 fax = +1 408 748-1032 From apollo-request@umix.cc.umich.edu Thu Aug 10 05:21:35 1989 Date: 9 Aug 89 09:50:45 GMT From: schmidt%cadlab%corona%unido%mcvax.uucp@uunet.uu.net (Michael Schmidt) Organization: CADLAB / Uni-GH Paderborn, Germany Subject: Once again: Routing under SR 9.7 Message-Id: <558@cadlab.cadlab.de> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have DN3000 with two Ethernet interfaces acting as a gateway between two Class-B-Internets (one with subnetting, one without). (Both nets are on the same physical ethernet, if it matters.) How must I set up the ROUTING between these two Internets? I have routing tables on both sides, but on the side without subnetting the table contains only foreign nets or hosts, but no entry for the other Class-B-Net (monitored on a Sun under SunOS 4.0.1). Any ideas? -- Michael Schmidt, CADLAB / FB 17, Uni-GH Paderborn, Bahnhofstr. 32, D-4790 Paderborn, West Germany Mail: schmidt@cadlab.UUCP or schmidt@cadlab.de From apollo-request@umix.cc.umich.edu Thu Aug 10 05:29:35 1989 Date: 9 Aug 89 12:37:22 GMT From: andrewn%syma%icdoc%ukc%mcvax.uucp@uunet.uu.net (Andrew D Nimmo) Organization: Univ. of Sussex, Brighton, UK Subject: lpd problems , X Windows Message-Id: <1220@syma.sussex.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Regarding recent questions about setting up lpd for an apollo network, we cannot get it to work as described in the administration manual. We are running SR10.1 ( and SR10.0P on a DN10000 ) - prmgr, prsvr and lpd run on the printing node, the spool queues are also on the printing node. If the other nodes on the ring have a spool directory with a file 'servername' specifying the printing node any print requests are queued but the warning 'no daemons present' is returned. The only way to cause printing to start is to restart (lpc) the required printer on the printing node. We do actually have lpd working by running lpd on every node, but with the printcap file giving the full pathname of the spool directory on the printing node (the only /usr/spool/lpd directory in the network). NB The DN10000 doesn't even work using the second method. Is this a problem with lpd, NCS or something else? On a completely different subject - I have X Windows Version 2, Revision 3 up and running on our network. When will apollo (UK or US) release their official version (with X Windows and DM support) and the MOTIF interface? Andrew D. Nimmo VLSI and Graphics Research Group, EAPS II, University of Sussex, Falmer, BRIGHTON, East Sussex. BN1 9QT, U.K. Tel: +44 273 606755 extn 2617 JANET: andrewn@syma.sussex.ac.uk UUCP: ...mcvax!ukc!syma!andrewn andrewn@syma.uucp -- this is a test of the sig From apollo-request@umix.cc.umich.edu Thu Aug 10 09:27:04 1989 Date: 10 Aug 89 09:21:30 GMT From: collins%nvpna1%prles2%prle%phigate%hp4nl%mcvax.uucp@uunet.uu.net (Donal O Coileain) Organization: Philips Research Labs (Nat Lab), Eindhoven, The Netherlands. Subject: Re: security hole Message-Id: <641@prles2.UUCP> References: <44e9d7d4.c4b0@apollo.HP.COM>, <511@eda.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <511@eda.com> jim@eda.com (Jim Budler) writes: >From Apollo? > > Every month, an invoice arrives. (Well, not any more 8^) Apollo produces a patch tape every month. In the 9.7 patch tape for JUNE 89 months before this discussion was started I read : "Patch 184 APR DCB34 : A security hole existed in the pad_$dm_cmd .......................... Now if the two user_ids are not equal, the command is disallowed and the following error status is returned: 'operation is illegal when no display is attached'" You cannot blame Apollo because you don't read the release notes or understand the bugs/fixes. >I fully agree with the posting of the bug. Look, INSTANT action. >Explicit mention of compatibility of /lib/streams. High awareness >in community of seriousness of bug. I see no problem in posting the problem, however I feel that it is not necessary to post the source code as well. Donal O Coileain. collins@apolloway.prl.philips.nl or collins%nvpna1.prl.philips.nl@uunet.uu.nl -- And out of the gloom a voice said, 'Smile and be happy for things could be a lot worse'. So I smiled and was happy and behold, things got worse -- From apollo-request@umix.cc.umich.edu Thu Aug 10 11:27:47 1989 Date: 10 Aug 89 13:20:07 GMT From: lau%kings.wharton.upenn.edu%netnews.upenn.edu%eecae%tank.uucp@handies.ucar.edu (Yan K. Lau) Organization: A Private Heaven Subject: Patches (was Re: security hole) Message-Id: <13613@netnews.upenn.edu> References: <44e9d7d4.c4b0@apollo.HP.COM>, <511@eda.com>, <641@prles2.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <641@prles2.UUCP> collins@nvpna1.UUCP (Donal O Coileain) writes: > >Apollo produces a patch tape every month. In the 9.7 patch tape for JUNE 89 >months before this discussion was started I read : > [deleted] > >You cannot blame Apollo because you don't read the release notes or >understand the bugs/fixes. > What prompted you to get the June patch tape? Do you routinely get patch tapes in case some bug is fix? Usually, I spend time on a problem to the point of not being able to solve it, then call Apollo. It would be nice if I knew something was not *my* problem (rare, it usually is) but a bug in the software. That way I don't waste my time. Without knowing what bugs and fixes exist, we're waiting for a problem to happen when we can prevent it if we knew. We've been through this time and time again. As far as I know, Apollo still does not routinely announce bugs/fixes. That is the problem. Yan. --- Yan K. Lau + the last message of a newgroup will be: )~ + a) longer than one screen & ~/~ lau@scrolls.wharton.upenn.edu + b) something you're not interested in. /\ University of Pennsylvania + your decision, 'n' key or space bar? From apollo-request@umix.cc.umich.edu Thu Aug 10 13:26:52 1989 Date: Thu, 10 Aug 89 10:28:33 CDT From: Andrew M. Wescott Message-Id: <8908101528.AA00372@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu Subject: Rebooting With EX on DN10000 We have a dn10000 with SR 10.1.p, FANG, the new boot proms, and the proper configuration via ee_config for the cartridge tape drive. The machine runs fine, except I can no longer reboot by using EX from the DM and then typing go at ). What I get is... Returned Status (from pm_$init): ok )go Loading Init pm_$init_mgrs failed (st 000E0014) So I type SHUT, and go all the way down. The status code given above is "insufficient rights", so I'd guess this is an ACL problem. Can someone save me some time and tell me what and where the problem is ? Many thanks, Andrew Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Thu Aug 10 13:29:42 1989 Date: Thu, 10 Aug 89 10:47:11 CDT From: Andrew M. Wescott Message-Id: <8908101547.AA00386@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu Subject: /usr/ucb/mail problems Well I guess this is my week to solve nagging little problems, so bear with me... We have (3) dn3500s and (1) dn10000 that are all on ethernet, and all are running sendmail. /usr/ucb/mail with our current configuration has worked fine for many months. Well now I have a dn3500 that is giving me fits. Whenever you send mail on this particular node whether it is by redirecting a file with <, reading in a file with ~r, or just typing in the message as you go, ONLY the header is sent --- not the message! I've really got a feeling of deja vu with this, but I can't remember what I did last time. Here are some other symptoms: 1.) This node is our spool node, and I've been getting a lot of blank messages with no headers lately that give me a Segmentation fault when I read them. 2.) I can't seem to get the node to pass ether.dex with the dn10000 as the partner (the other dn3500s are too far away). When I do a nodestat -l, no particular statistics jump out at me as problems. Help! Andrew Wescott University of Houston Department of Chemical Engineering p.s. We are running SR 10.1 and SR 10.1.p, and the environment is bsd4.3. From apollo-request@umix.cc.umich.edu Thu Aug 10 17:28:43 1989 Date: 10 Aug 89 19:03:21 GMT From: jwright%atanasoff%dino.uucp@uunet.uu.net (Jim Wright) Organization: Iowa State U. Computer Science Department, Ames, IA Subject: Re: security hole Message-Id: <1324@atanasoff.cs.iastate.edu> References: <44e9d7d4.c4b0@apollo.HP.COM>, <511@eda.com>, <641@prles2.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <641@prles2.UUCP> collins@nvpna1.UUCP (Donal O Coileain) writes: | | Apollo produces a patch tape every month. | | You cannot blame Apollo because you don't read the release notes or | understand the bugs/fixes. I don't happen to have the clout of Phillips Research Labs. I don't get a patch tape every month, or even an announcement. In fact, this is the first I've heard of it. But enough whining. I'd like to offer some constructive help. The last time the patch issue was raised, there were some noises about the University of Iowa setting up an anonymous ftp site which archived all the patches. Apparently it has died; I haven't heard a peep out of them since. As part of the anti-viral archives, in conjunction with comp.virus/VIRUS-L, we are setting up a site for Unix systems. To start this, we already have bug fixes for Sun, Pyramid and DEC. We would be pleased to make the Apollo patches available too. If someone from Apollo could respond here, contact me, or give me a lead as to who to contact at Apollo, I would appreciate it. Also, opinions from the net as to whether this is good or bad would be helpful. Perhaps if enough interest is shown, it will happen. I know that anonymous ftp is not available to everyone. But as it stands now, you apparently have to be a mega-corporation with an inside track to Apollo to get access to bug fixes. (My perception; am I wrong?) -- Jim Wright jwright@atanasoff.cs.iastate.edu From apollo-request@umix.cc.umich.edu Fri Aug 11 01:19:32 1989 Date: 10 Aug 89 23:59:28 GMT From: anderson%spanky.sps.mot.com%dover%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu Organization: Motorola, Inc., Semiconductor Products Sector Subject: Failure of tb after aqdev Message-Id: <1672@dover.sps.mot.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Release 10.1, dn3550: When aqdev is used to acquire a device and the device is successfully acquired, traceback no longer works. Any program that aborts while the device is acquired shows nothing when tb is invoked. This makes it a little difficult to debug programs that use the device. At least this is the situation on my node. Any ideas regarding how to get a tb after a device is acquired?? (I sure hate to go back to inserting print statements...) Howard C. Anderson ...sun!sunburn!dover!anderson From apollo-request@umix.cc.umich.edu Fri Aug 11 01:20:48 1989 Date: 10 Aug 89 20:25:15 GMT From: ins_bxl%jhunix%aplcen%indri%uakari.primate.wisc.edu.uucp@csd4.milw.wisc.edu (Xuyong Liu) Organization: The Johns Hopkins University - HCF Subject: DOMAIN_OS 10.1 accounting problem Message-Id: <2262@jhunix.HCF.JHU.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have a DN4000 running BSD4.3 under DOMAIN_OS 10.1. For some unknown reason, whenever the accounting is turned on (by "/etc/accton /usr/adm/acct"), the system is badly slowed down -- from time to time, one has to wait for ten seconds before getting the prompt back. Normally, there are only two or three users on the system and no one is really taking too much CPU time. And the size of /usr/adm/acct does not increase very rapidly. Any one out there knows the reason for this problem and the way to fix it? Thanks for any help in advance. ________ liu@alpha.ece.jhu.edu ins_bxl@jhunix.hcf.jhu.edu From apollo-request@umix.cc.umich.edu Fri Aug 11 05:19:53 1989 Date: 10 Aug 89 18:47:44 GMT From: kts%quintro%tiamat.uucp@uunet.uu.net (Kenneth T. Smelcer) Organization: none Subject: Re: security hole Message-Id: <1989Aug10.184744.11583@quintro.uucp> References: <44e9d7d4.c4b0@apollo.HP.COM>, <511@eda.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <511@eda.com> jim@eda.com (Jim Budler) writes: > >We regret that it took such a blunt step to cause Apollo to bother to >tell us that the hole exists, and has fixes. > >From Sun Microsystems? > > Every quarter, a thick book arrives in the mail, detailing >bug reports. > > Every month, a book arrives in the mail, containing >interesting Technical details. > Mentor Graphics does the same thing for its Apollo customers. Every month we get a book with technical tips for Sys Admins, followed by a list of current bugs, work-arounds, and bug fixes for their entire product line. It would be great if Apollo would do something like this. It would save them money in fewer calls to the Hotline, and it would enhance their image (I tend to get real ticked off when I spend 2-3 days trying to fix something that Apollo already knows doesn't work.) Who knows, maybe with HP taking control, Apollo will show more interest in taking care of their current customer base, as well as trying to open new markets. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ken Smelcer Quintron Corp. quintro!kts@lll-winken Quincy, IL tiamat!quintro!kts@uunet From apollo-request@umix.cc.umich.edu Fri Aug 11 07:20:47 1989 Date: 9 Aug 89 22:18:07 GMT From: larry%larry.fpssun.fps.com%nosun%cvedc%ogccse%blake%caesar%indri%uakari.primate.wisc.edu.uucp@ (Larry Breniser ext 2282) Organization: Floating Point Systems Subject: sio lines autobaud under 9.7? Message-Id: <542@larry.fpssun.fps.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I would like to know if it is possible to get the sio line on an Apollo to autobaud to different incoming baud rates. Could I log in to an Apollo using my 9600 baud terminal at work, and use the same line to access it from my 2400 baud modem at home? Larry From apollo-request@umix.cc.umich.edu Fri Aug 11 11:26:27 1989 Date: Fri, 11 Aug 89 10:01:18 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8908111401.AA01735@richter.mit.edu> To: anderson%spanky.sps.mot.com%dover%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu, apollo@umix.cc.umich.edu Subject: Re: Failure of tb after aqdev Hmmm ... my understanding of /com/aqdev under SR9.7 is that the program acquires the device (ie. reads the ddf file, loads and initializes the device libraries) and then uses pgm$invoke to start a shell which then executes your commands. Under SR9.7 the shell seems to be invoked in-process (ie. no new processes show up on the system when /com/aqdev is run). If I quit out of a program which is using the previously acquired device I can get a traceback just fine. SR10 is a different matter ... when you use /com/aqdev to aquire a device under SR10, you start a new process which runs the aqdev program. When you then run your application, yet another process gets started to handle that. When the application dies (or you quit out of it), the process goes away just like real Unix processes do ... but, the system does keep a process dump file which may contain enough info for you to get a traceback. You will need to use the "tb" command with one of the following options (I don't know which will work in your case): "-last" will traceback the last process in the dump file (which could be another process which died just after yours), "-command" will look for the last dump which came from a process running a particular command line, "-proc" will look for a dump from a particular Unix PID, an Aegis UID, or a process name. One of these options should be able to find the dump of your application and give you the traceback. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Fri Aug 11 13:22:14 1989 Date: 11 Aug 89 15:06:30 GMT From: micky%cunixc.uucp@columbia.edu (Micky Liu) Organization: Columbia University Subject: Help with 3D Graphics and X Message-Id: <1777@cunixc.cc.columbia.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am attempting to build an application using X to control the windowing, but I also need to display some 3D graphics in one of the windows. So what I'm planning to do is to use some graphics library like PHIGS to draw directly to the frame buffer and limit its output to the boundaries of the 3D window. If there are any resize-type events, I'll have to somehow get my program to re-fit the location of the viewable 3D graphics frame buffer and possibly redraw it if it becomes exposed. Does this sound like the way to go? Any other suggestions as to how to mix 3D graphics and X? Please don't tell me to wait for PEX... Please respond directly to me by mail, I will summarize to the net if people are interested. Thanx! Micky arpa: micky@cunixc.cc.columbia.edu uucp: ...!rutgers!columbia!cunixc!micky bitnet: malua@cuvmc From apollo-request@umix.cc.umich.edu Fri Aug 11 15:23:24 1989 Date: 11 Aug 89 13:12:24 GMT From: i91%nikhefh%mcvax.uucp@uunet.uu.net (Fons Rademakers) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: /bin/csh and /bin/sh hang sometimes Message-Id: <237@nikhefh.hep.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi, Lately I am observing the following problem: after log in when /bin/start_csh is executed (SR9.7) it takes a very long time before I get a prompt. Also running shell scripts written in /bin/sh take very long to execute. To find the problem I traced with DPAT a shell script and it turns out that the system is waiting in the routine (?) SVC! for a very long time. Then suddenly it continues. The only remedy I've found so far is shutting and rebooting the node (a DN580-T). What is SVC! doing? How can this problem be fixed? Cheers, Fons Rademakers. -- Org: NIKHEF-H, National Institute for Nuclear and High-Energy Physics. Mail: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: (20)5925018 or 5925003 Telex: 10262 (hef nl) UUCP: i91@nikhefh.hep.nl BITNET: nikhefh!i91@mcvax.bitnet From apollo-request@umix.cc.umich.edu Fri Aug 11 17:26:00 1989 Message-Id: <8908112041.AA15530@umix.cc.umich.edu> Date: 11 Aug 89 14:16:00 MDT From: "2647 Bickel, Douglas L." Subject: Help, how do I get off the Apollo mailing list? To: "apollo" Please remove me from the Apollo mailing list. I don't seem to know how to get off the list. Thanks. From apollo-request@umix.cc.umich.edu Fri Aug 11 17:35:23 1989 Date: 11 Aug 89 19:52:10 GMT From: braner@tcgould.tn.cornell.edu (Moshe Braner) Organization: Cornell Theory Center, Cornell University, Ithaca NY Subject: SCSI adaptors, floppy drives Message-Id: <8610@batcomputer.tn.cornell.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I'd like to find out what is available in the following categories for an Apollo Domain 3500 workstation. Both hardware and the necessary software would need to be found. SCSI adaptor: we have a portable SCSI tape drive that could be used for backing up the hard drive in the Apollo. How can we get it connected? Floppy drive: this is another backup option, and could also serve for easy Apollo (and the net) <--> IBM PC/AT file transfer. Can one get a 1.2 Meg 5.25" or a 1.44 Meg (or 720K) 3.5" drive? Can it read/write MS-DOS format files? Or only UNIX files? Both? Thanks. - Moshe Braner Cornell Theory Center, 265 Olin Hall, Cornell University, Ithaca, NY 14853 USA (607) 255-9401 (INTERNET) (BITNET) From apollo-request@umix.cc.umich.edu Fri Aug 11 17:39:13 1989 Date: Fri, 11 Aug 89 16:47:49 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8908112047.AA03831@richter.mit.edu> To: anderson@spanky.sps.mot.com Subject: Re: Failure of tb after aqdev Cc: apollo@umix.cc.umich.edu Hmm ... sounds like /com/aqdev may have its own fault handler set up, in which case the system fault handler might not ever see the fault and would not write the process dump. Without seeing the source code, I can only guess at what is going on. Can anyone at Chelmsford pass this on to the Apollo corporate mailing list for comment? -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Fri Aug 11 17:41:04 1989 Date: Fri, 11 Aug 89 16:43:12 edt From: peter@archie.whoi.edu (Peter R. Shaw) Message-Id: <8908112043.AA01139@> To: apollo@umix.cc.umich.edu Subject: HP's new 3D graphics workstation I was thumbing through the June issue of Computer Graphics World when I noticed a big glossy ad that HP has out for its *new* color 3D graphics workstation. (sorta reminiscent of a DN4000 or something, although definitely an HP, NOT Apollo). I guess an obvious couple of questions is: (1) seeing as how HP just bought a leader in 3D graphics workstations, wouldn't you expect that the A-word would have been used somewhere in the new advertising campaign? -- conversely, -- (2) If HP has decided to go into the business of manufacturing its own Apollo-style workstations (apparently without actually involving Apollo), why did they feel compelled to buy them out in the first place? Oh, and I suppose: (3) Should present and potential future Apollo owners be concerned? Peter Shaw pshaw@aqua.whoi.edu From apollo-request@umix.cc.umich.edu Fri Aug 11 17:44:41 1989 Date: 11 Aug 89 19:35:10 GMT From: michal%kuhub.cc.ukans.edu%wupost%wugate.uucp@uunet.uu.net (Merlin The Magician) Organization: University of Kansas Academic Computing Services Subject: Accounting ? Message-Id: <8432@kuhub.cc.ukans.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi Y'all, My boss has recently asked me to come up with reports about usage of 16 DN4000 Apollo workstations that we support for the School of Engineering. Obviously some accounting software will be nice to have in order to get some data. The only thing that there is on the system that I have found is the printer/plotter accounting. I can handle in some crude way disk usage accounting, just go over each directory of every user and collect the grandtotals. More difficult will be process accounting and for instance, restricting people to use only X Kbytes of disk space. I saw some message here where there was a mention of accouting software. Is it something that Apollo makes and we don't have it ? Or better, is it public domain, or still better, can I use it ? Any responses will be greatly appreciated. Either post or e-mail. -- Merlin +------------------------------+----------------------------------------------+ | Michal Chmielewski \ The inherent vice of capitalism is the | | Academic Computing Services \ unequal sharing of blessings; the | | University of Kansas \ inherent virtue of socialism is the | | Lawrence, KS 66045 \ equal sharing of miseries. | | Internet: michal@kuhub.cc.ukans.edu - Winston Churchill | | BitNet : michal@ukanvax.bitnet \ | +-------------------------------------+---------------------------------------+ From apollo-request@umix.cc.umich.edu Fri Aug 11 21:22:23 1989 Date: 11 Aug 89 15:48:00 GMT From: tim%hi-csc.uucp@uunet.uu.net (Tim Giebelhaus) Organization: mpls Subject: Re: lpd problems , X Windows Message-Id: <642@tim.UUCP> References: <1220@syma.sussex.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1220@syma.sussex.ac.uk> andrewn@syma.UUCP (Andrew D Nimmo) writes: > > Regarding recent questions about setting up lpd for an apollo network, > we cannot get it to work as described in the administration manual. > > We are running SR10.1 ( and SR10.0P on a DN10000 ) - > > prmgr, prsvr and lpd run on the printing node, the spool queues are > also on the printing node. What I take it that you are tring to do is to be able to print with both prf and lpr. Does the prf work? If prf will not work, then you do not stand much of a chance of getting lpr to work. I take it the printcap looks like: lp|line printer:\ :pc=/com/prf -banner off -text -npag -headers off:lp=/dev/null:\ :sd=/usr/spool/lpd/lp:if=/usr/lib/lpf:\ :af=/usr/adm/lpacct:lf=/usr/adm/lpd-errs: This should send unix prints to the aegis printing system. > If the other nodes on the ring have a spool directory with a file > 'servername' specifying the printing node any print requests are > queued but the warning 'no daemons present' is returned. The only > way to cause printing to start is to restart (lpc) the required > printer on the printing node. > > We do actually have lpd working by running lpd on every node, but > with the printcap file giving the full pathname of the spool > directory on the printing node (the only /usr/spool/lpd directory > in the network). I do not understand this part. It looks as if you are attempting two different methods of printing. If you are going to run lpd on each node, then you should not attempt to set the 'servername' file. If you are going to run lpd in the pure unix way, all lpd's on machines which are not directly connected to the printer should use the 'rm' specification of the printcap file to tell lpd to send the job to the machine with the printer. -- UUCP: uunet!hi-csc!apcimsp!tim ARPA: tim@apollo.com Contents of this message has nothing to do with work. From apollo-request@umix.cc.umich.edu Sat Aug 12 09:24:04 1989 Date: 12 Aug 89 06:48:41 GMT From: abair%oakhill%cs.utexas.edu%execu%sequoia%texbell%texsun%newstop%sun-barr.uucp@decwrl.dec.com (Alan Bair) Organization: SPS CAD, Motorola Inc., Austin, Texas. Subject: Re: lp spooling with lpd under 10.1 Message-Id: References: <2474@orion.cf.uci.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I had no trouble running a separate lpd on each node after I fixed the various permissions on all the required files. I don't know if it was installed badly, open vs closed or what, but owner, group, setuid, setgid, etc were all in various states other than what they should be. I just set them up as the UNIX sysadmin book indicated. Alan Bair SPS CAD Austin, Texas Motorola, Inc. UUCP cs.utexas.edu!oakhill!turbinia!abair From apollo-request@umix.cc.umich.edu Sat Aug 12 09:28:41 1989 Date: 12 Aug 89 07:02:54 GMT From: abair%oakhill%cs.utexas.edu%execu%sequoia%texbell%texsun%sun-barr.uucp@apple.com (Alan Bair) Organization: SPS CAD, Motorola Inc., Austin, Texas. Subject: Re: lpd problems , X Windows Message-Id: References: <1220@syma.sussex.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1220@syma.sussex.ac.uk> andrewn@syma.sussex.ac.uk (Andrew D Nimmo) writes: Regarding recent questions about setting up lpd for an apollo network, we cannot get it to work as described in the administration manual. See my follow up to the first lpd question: 1)Had to correct file permissions according to sysadmin book 2)Have to run copy on each node with own queue. However, we print to a remote Sun printer. We are running SR10.1 ( and SR10.0P on a DN10000 ) - prmgr, prsvr and lpd run on the printing node, the spool queues are also on the printing node. If the other nodes on the ring have a spool directory with a file 'servername' specifying the printing node any print requests are queued but the warning 'no daemons present' is returned. The only way to cause printing to start is to restart (lpc) the required printer on the printing node. I seem to remember reading something in the release notes for SR10.1 that indicated a need to restart after each print request. It was a known bug and I think they gave a kludgy work around. We do actually have lpd working by running lpd on every node, but with the printcap file giving the full pathname of the spool directory on the printing node (the only /usr/spool/lpd directory in the network). NB The DN10000 doesn't even work using the second method. One of our 2 nodes is a DN10000 and I got it to work, but then it is running SR10.1.p Is this a problem with lpd, NCS or something else? On a completely different subject - I have X Windows Version 2, Revision 3 up and running on our network. When will apollo (UK or US) release their official version (with X Windows and DM support) and the MOTIF interface? Another person in our group managed to get a Beta release of Domain/X11, Shared X, from Apollo. I am not sure what restrictions were placed on it. He also seems to think it will be a released product in a couple months, but this is all speculation. Apollo/HP - Any comments? Alan Bair SPS CAD Austin, Texas Motorola, Inc. UUCP cs.utexas.edu!oakhill!turbinia!abair From apollo-request@umix.cc.umich.edu Sat Aug 12 17:28:45 1989 Date: 12 Aug 89 17:38:20 GMT From: kerr%tron%umbc3%haven%uflorida%mailrus.uucp@tut.cis.ohio-state.edu (Dave Kerr) Organization: Westinghouse Electronic Systems Group, Baltimore, MD Subject: Re: DOMAIN_OS 10.1 accounting problem Message-Id: <433@tron.UUCP> References: <2262@jhunix.HCF.JHU.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <2262@jhunix.HCF.JHU.EDU> liu@alpha.ece.jhu.edu writes: > >We have a DN4000 running BSD4.3 under DOMAIN_OS 10.1. For some unknown >reason, whenever the accounting is turned on (by "/etc/accton >/usr/adm/acct"), the system is badly slowed down -- from time to time, one >has to wait for ten seconds before getting the prompt back. Normally, there >are only two or three users on the system and no one is really taking too >much CPU time. And the size of /usr/adm/acct does not increase very rapidly. >Any one out there knows the reason for this problem and the way to fix it? > Is this a stand alone node? If so try turning network services off (via the netsvc command). We noticed a similar problem. It appeared that the node was trying to query a non-existant network and the node was slowing down waiting for the request to time out. Disabling network services restored the node to normal. -- Dave Kerr (301) 765-4453 kerr%tron.UUCP@umbc3.UMBC.EDU from an Internet site kerr@tron.UUCP from a smart uucp mailer {well-connected-site}!netsys!tron!kerr from a dumb uucp mailer From apollo-request@umix.cc.umich.edu Sun Aug 13 01:22:30 1989 Date: 22 Jul 89 16:35:02 GMT From: achille%cernvax%mcvax.uucp@uunet.uu.net (achille petrilli) Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Subject: Re: Apollo - Sun TAR transfers Message-Id: <1025@cernvax.UUCP> References: <1130@servax0.essex.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1130@servax0.essex.ac.uk> martin@essex.ac.uk (Colley M) writes: >............ They suggested the aegis >command: > > edmtdesc /dev/rct8 -s reo no > >Which changes the attribute "reo" to "no" (dont forget to set it back to >"yes" as rbak/wbak wont work properly). Then use tar as normal. This >worked for us under aegis (Domain/IX) 9.5/9.7. I haven't tried it at 10.1 >yet. > >Hope this is helpful. > >Martin Colley This story of wbak/rbak not working properly if you change /dev/rct8 is just plain wrong. W/Rbak use /lib/tfp to access the tape/cartridge. /dev/rct? is just an additional layer on top of, I guess, /lib/tfp to make it possible to access the device the "Unix way", i.e. as a file. Wbak, rbak, rwmt do not use the /dev files in any way, that is the reason why they are much faster than any user-written program that accesses the devices via /dev/rct?. On a, more or less, related argument, I'd like to know if somebody has tested/used the new backup facility from Apollo, NBS Omniback. I'm interested in hearing any quirks/problems you had and about its performance. Also, we have a few Exabytes from Workstation Solutions and whatever is written on the Apollo is unreadable both on Sun and VMS (Viking controller, TK50 driver), but both Sun and VMS written cassettes are readable on Apollo. The message I get is 'illegal block length' (that's the semantic content of it :-). Anyone can help ? Achille Petrilli Cray & PWS operations From apollo-request@umix.cc.umich.edu Sun Aug 13 05:19:09 1989 Date: 13 Aug 89 06:54:17 GMT From: culmer%grad1.cis.upenn.edu%netnews.upenn.edu.uucp@rutgers.edu Organization: University of Pennsylvania Subject: Segmentation violation on procedure return Message-Id: <13670@netnews.upenn.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu This might be just a C language question, but I figure I can cover all of the bases by asking the question first in this newsgroup. I sometimes get segmentation violations when function calls (without any return values) return. (The error definitely occurs between my last line of the function and my first line of the calling function after the call.) I can't account for this with my knowledge of C, segmentation, the stack, and the heap. I have experienced the same problem sometimes when I declare a pointer to a structure in the function but forget to allocate space for the structure. Even then, I don't understand why the segmentation violation occurred when the function returned if I was able to make assignments to the members of the "structure" without a segmentation violation. Thanks in advance. Charles W. Culmer culmer@grad1.cis.upenn.edu Truth, justice, and the Canadian way From apollo-request@umix.cc.umich.edu Sun Aug 13 17:23:24 1989 Date: 11 Aug 89 10:59:13 GMT From: lambert%cheops%elecvax%usage%basser%metro%otc%munnari.oz.au%uhccux.uucp@ames.arc.nasa.gov (Timothy Lambert) Organization: EE & CS, Uni N.S.W., Sydney, Australia Subject: Re: GPR->XWD Bitmap conversion Message-Id: <1238@cheops.eecs.unsw.oz> References: <8908081257.AA03206@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >From article <8908081257.AA03206@umix.cc.umich.edu>, by FERGUSON@TMASL.EXXON.COM: > Is there a conversion program in or out of X-Apollo for changing > GPR bitmaps into XWD (X-Window Dump) format? Obviously, you could > grab the picture off the screen, but a way to do it without using > the display would be nice for printing to remote printers that > don't know what a GPR bitmap is. I have written programs to convert between GPR bitmaps and pbm type bitmaps. You can then use the pbm tools to convert it to xwd. Mail me if you want them. Tim Lambert lambert@cheops.eecs.unsw.oz lambert%cheops.eecs.unsw.oz@uunet.uu.net ...!uunet!munnari!cheops.eecs.unsw.oz!lambert From apollo-request@umix.cc.umich.edu Mon Aug 14 07:35:55 1989 Message-Id: <8908140934.AA18876@umix.cc.umich.edu> Date: Mon, 14 Aug 89 17:31:41 SST From: fclim Subject: RE: Accounting ? To: One ADU to another In article <8432@kuhub.cc.ukans.edu> michal%kuhub.cc.ukans.edu %wupost%wugate.uucp@uunet.uu.net (Merlin The Magician) writes: > My boss has recently asked me to come up with reports about usage > of 16 DN4000 Apollo workstations that we support for the School of > Engineering. Obviously some accounting software will be nice to have > in order to get some data. The only thing that there is on the system > that I have found is the printer/plotter accounting. > > I can handle in some crude way disk usage accounting, just go over > each directory of every user and collect the grandtotals. > More difficult will be process accounting and for instance, > restricting people to use only X Kbytes of disk space. > > -- Merlin I don't know whether Apollo Domain/OS (ie SR10+) has disk quota or disk usage accounting, but you can switch on process accounting via "/etc/accton". This command is documented in the "Managing your BSD software" manual for sys-admins. The man page is in Section 8 and listed under (surprising) /etc/sa. You *don't* need to install the BSD environment to have the accounting facility. fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Add your pet peeve If we think really hard, maybe we can stop this ____! No ____! No ____! No ____! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From apollo-request@umix.cc.umich.edu Mon Aug 14 09:24:44 1989 Message-Id: <8908140941.AA18979@umix.cc.umich.edu> Date: Mon, 14 Aug 89 17:34:04 SST From: fclim Subject: DM keys definitions and Unix shells. To: One ADU to another The Domain/OS man pages (BSD) on C SHELL sez that Apollo has implemented the filename expansion facility. Suppose % ls bar foobar haha then if we % set filec we have switched on this facility. Now, when we type % vi f C shell will expand the line to % vi foobar This works with ~user; suppose we wish to replace user ah-fock's .cshrc with user ah-lok's version, we may (as root) in a C shell, type in % cpf -r ~ah_l which becomes % cpf -r ~ah_lok where we continue typing % cpf -r ~ah_lok/.cshrc ~ah_f which expands to % cpf -r ~ah_lok/.cshrc ~ah_fock assuming that there are no other user with the prefixes ah_l or ah_f. This works in a DM shell input pad. My question is: will this still work if we change the default DM's definition of the key? What happen if we % /com/xdmc kd esc ke or % /com/xdmc kd esc cp /bin/csh ke (Please don't ask me why I know about this when I do not have SR10+; it's a long story). While we are talking about the DM interfaces with a C shell (or Unix shells), I like to bring something similar up. At SR9.7 (and at least at SR10.1), the Unix command "stty" has a lot of no-ops on DM input pads. For example, suppose that when I login, the DM defines the keys as in /sys/dm/std.basics instead of /sys/dm /std.unix or similar. Thus ^Z is EOF. Now, if I issue the command % stty eof ^D stty will not issue any warning; but the EOF char is still ^Z. Similarly, the following is a no-op % stty -echo These stty options and others work if we pull the pad into PAD_$raw mode via /com/vt100, telnet, rsh, rlogin, etc. But then, we will lose the scrollability and the quarter-plane of the transcript pad since when we enter PAD_$raw mode, we lose the transcript pad. There are times when I like to invoke % make :: echo "make returns OK^G" & ie if make returns 0, a message is printed. Because this is put into the background, this message can be confused with output from the foreground job. So I put in a bell, ^G. But I can't get this to work at SR9.7; I'm not sure about SR10+. I do not wish to resort to SysV echo (/sysV/bin/echo "make returns OK\07") or vt100 or to use vi to create a file with a bell in it and then cat that file. Is it possible to write the OS so that the DM filters keystrokes to a /com/sh pad, but when we have a Unix shell (either through "cp /bin/{csh,ksh,sh}" or "cp /sys/dm/login_sh"), the DM only filters the grey keys but leave the cooking to the line discipline for the other white keys? Of course, the DM still have the task of sending the keystrokes only to the pad under the cursor (context). I'd love to change the world But I don't know what to do So I leave it up to you Alvin Lee (Ten Years After) fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Add your pet peeve If we think really hard, maybe we can stop this ____! No ____! No ____! No ____! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From apollo-request@umix.cc.umich.edu Mon Aug 14 09:28:10 1989 Message-Id: <8908140932.AA18839@umix.cc.umich.edu> Date: Mon, 14 Aug 89 17:28:18 SST From: fclim Subject: RE: question about path setup under sr10.1/bsd4.3 To: One ADU to another In article <44d047e0.1b147@apollo.HP.COM> nazgul%apollo%ulowell% mailrus.uucp@ames.arc.nasa.gov (Kee Hinckley) writes: > In article <13400@netnews.upenn.edu> lau@kings.wharton.upenn.edu > (Yan K. Lau) writes: > > How does one change the default path of users when they log > > into a node or create a shell under SR10.1/BSD4.3? > > We have both Aegis and Unix running. Some users use the > > C shell or Bourne shell and others use the Aegis shell. > > In the Bourne and Korn shells you can do it by changing > /etc/profile and /etc/profile.ksh. Neither the C shell or > the Com shell have means of doing this, however with the > Com shell you could try (I don't guarantee this though > since at login the shell might ignore it) setting the > environment variable "CSR" in the DM login scripts. > Otherwise the best way is to simply install a > default .login or $HOME/user_data/sh/login script for > every user. In the book "The Unix C Shell Field Guide" by Gail and Paul Anderson, (Prentice-Hall publisher; ISBN: 0-13-937468-X 025), on page 354, the authors write that C shell execute the file /etc/cshrc (or /etc/cshprofile) before going on to ~/.cshrc. This is not implemented in the SR9- nor SR10+ C shells. HP/Apollo: why? How about adding it to SR11? Kee gives the advice of creating a .login for each user. It should be .cshrc in this case, since .login is only read by /sys/dm/login_sh or /bin/start_csh; any new shell created using "cp /bin/csh" will skip .login. I don't like the idea of setting the path in /etc/{profile,profile.ksh, cshrc}. Users should be educated to set their own path; tell them where the utilities are in. If you hide such information from them (especially novices), they might use Aegis commands with wild-cards in a Unix shell. This may lead to disastrous results: > From: reesd%gtephx%hrc%asuvax.uucp@handies.ucar.edu (David Rees) > Subject: Re: Aliases For Aegis Commands > Message-Id: <44c14aa1.f9df@gtephx.UUCP> > > In article <1632@dover.sps.mot.com>, turner@dover.sps.mot.com > (Robert Turner) writes > > First I know this is a wimpy question, but what the heck. I'm > > an old Aegis kind of guy slowing migrating to BSD on SR10+. > > What I'm looking for is a set of aliases for some of the more > > common Aegis commands, e.g. cpf, dlf, dlt, crd, crl, wd, etc. > > My fingers keep typing Aegis commands while my brain is saying > > BSD, BSD, BSD! > > First of all you must be carefull when making aliases for aegis to unior > the other way around. For instance I tried to make an alias for cpf: > %alias cp cpf > > This is WRONG! First of all cpf does all its copying in pairs while > cp copies all the items to the last item. > > $cpf F1 F2 F3 F4 > F1 -> F2 (F1 is copied to F2) > F3 -> F4 (F3 is copied to F4) > > %cp F1 F2 F3 F4/ > F1 F2 F3 -> F4 (They are copied into F4) > > And second of all with the Unix shells (Bourne and C) the regular > expressions are expanded by the shell, while in Aegis it seems like > the expressions are expanded by the command. For instance I typed > the following: > > %cpf ?*.c ./backup -r <--- DON'T DO THIS! > > While this is right out of the manual I missed a critical detail. > The '%' > instead of the '$'. Since the C shell expanded the wildcard first, > it sent > cpf a list of the files and then cpf proceeded to replace every other > file (about three weeks worth of work, thank god for backups). > > -David fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Add your pet peeve If we think really hard, maybe we can stop this ____! No ____! No ____! No ____! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From apollo-request@umix.cc.umich.edu Mon Aug 14 09:31:45 1989 Message-Id: <8908140928.AA18824@umix.cc.umich.edu> Date: Mon, 14 Aug 89 17:19:57 SST From: fclim Subject: RE: security bug (hole) To: One ADU to another I like to put my 2 cents into this. I have discovered rdmc on my own before Peter Lipp announced it. It was kind of experimental and I use it once in a while to shut all nodes in the ring: % foreach x (//*) rsh $x:t rdmc shut end or use it to log out someone (I was experimenting with a time-quota in a similar sense as a disk-qouta): % rsh node rdmc "lo -on; lo" I have never thought of the convoluted DM command: > rdmc "kd cr en;dr;kd cr xc -f '/tmp/pw' ;en;kd cr en ke ke ke" to crowbar the passwd right under the user's nose. I am new to programming with Aegis system calls; and I don't spend much time writing such programs 'cos I'd rather use Unix calls instead. If I can write rdmc, I am sure others better than myself are able to do so, whether Peter has submitted the source or not. Peter has done us a great service by publishing the source; it shows that *** the DM is either too powerful or too loose. *** Apollo oughta scale it down by removing certain commands from it or checking the SID/ACLs on the commands. /**********************************************************/ I like to share a couple of ideas I have for some time now. They concern trojan horses. On vanilla Unix w/o a windowing system like Apollo DM (ie only a glass tty is available) (eg Xenix on an IBM PC w/o X), it is easy to write a trojan horse. The trojan (shell script or otherwise) displays a login prompt inviting users to log in. Whether it logs in the user or not, it will capture the passwd. It is possible to imitate the Apollo login screen for the purpose of capturing passwds by using gpr_$borrow mode and pad_$dm_cmd() call. The latter call (pad_$dm_cmd) is not used to log in the user (because it can't be done), but is used to call the DM command msg to print the "wrong passwd" message on the DM output pad. There are still some more work to be done to avoid arousing the user; but I believe I can produce a program to trick some of the people (especially naive novices) some of the time. I have 2 solutions. The first one uses the behavior of init(8), the Adam and Eve process found in Unix and recently in Domain/OS. On a successful login, init spawn a shell and then it (init) goes to sleep. At logout, init awakes and waits upon another login(1). (This is roughly what happens; I have left out all the juicy parts). The idea is to have a front-panel LED to reflect the status of init. When no one is logged in on that node, init is awake and the LED lights up or blinks. If the LED is not blinking, either the LED had KOed or someone has logged in and left a trojan; users log in at their own risk. No system call can turn this LED on. The 2nd idea is to throw out gpr_$borrow mode in a sense. Applications may still enter into borrow mode; but instead of 1024 by 800, only 1024 by 780 pixels are writable. Thus, no one can write codes to imitate the DM input pad. System calls should be available to blacken this portion or to send text to this portion. For the latter purpose, the portion is treated as a one-line glass tty: text appears in this region in the same manner as the electronic billboards (whatChaCallIt?) found in Manhattan's Time Square or Wall Street where the text scroll horizontally. Commands like send_alarm, wall(1), write(1) attempt to create a pad; on failure, they writes to the bottom of the borrowed screen. fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Add your pet peeve If we think really hard, maybe we can stop this ____! No ____! No ____! No ____! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Self-adhesive labels with following note: ___ If this is not blinking, / log in at your own risk. / v are on sale at 10 cents a piece. Residents of the People's Republic of Massachusetts, please add state tax. From apollo-request@umix.cc.umich.edu Mon Aug 14 13:24:35 1989 Date: Mon, 14 Aug 89 11:39:44 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8908141539.AA08684@richter.mit.edu> To: achille%cernvax%mcvax.uucp@uunet.uu.net, apollo@umix.cc.umich.edu Subject: Re: Apollo - Sun TAR transfers >From talking to some Sun users who have Exabyte drives, I've gotten the impression that the SCSI specs are kind of loose. Apparently even various implementations of the Exabyte drive for the Sun-3 and Sun-4 systems can not always talk to each other due to variations in the SCSI driver. Maximum block lengths and the use of "short" vs. "long" file marks seem to be the problem in most cases. Given your error message, I'd guess that Workstation Solutions' SCSI driver is writting longer physical records on the tape than the Sun and Vax implementations can handle. Terri Long of Wrokstation Solutions told me that their driver can be coerced into using the same parameters as the other SCSI drivers by twiddling with the DDF file in some manner (I think they may have some flags set in the user-info block which can be changed with the /com/crddf command). Try calling W.S. to see if you can change the maximum block size of the driver. == Dave From apollo-request@umix.cc.umich.edu Mon Aug 14 13:29:01 1989 Date: 14 Aug 89 14:21:09 GMT From: reb%quintro%tiamat.uucp@uunet.uu.net (Roger E. Benz) Organization: none Subject: Re: SCSI adaptors, floppy drives Message-Id: <1989Aug14.142109.1781@quintro.uucp> References: <8610@batcomputer.tn.cornell.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8610@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu (Moshe Braner) writes: >I'd like to find out what is available in the following >categories for an Apollo Domain 3500 workstation. > >Floppy drive: this is another backup option, and could also serve >for easy Apollo (and the net) <--> IBM PC/AT file transfer. >Can one get a 1.2 Meg 5.25" or a 1.44 Meg (or 720K) 3.5" drive? >Can it read/write MS-DOS format files? Or only UNIX files? Both? > Apollo has a floppy available that will meet your needs. It can read write MS-DOS high dense floppies if you get the hardware or software PC compatibility products. It does not read/write low dense floppies very well. As for UNIX floppies you can either mount the floppy, use wbak/rbak or tar. The cost, if you have a hard disk, is about $500 for the floppy. The PC software emulator is about $500 and the PC hardware emulator is $2K-$3k. -- 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 Mon Aug 14 13:32:51 1989 Date: 14 Aug 89 16:06:18 GMT From: hollaar%basset.utah.edu%wasatch%helios.ee.lbl.gov%agate.uucp@ucbvax.Berkeley.EDU (Lee Hollaar) Organization: University of Utah CS Dept Subject: Re: SCSI adaptors, floppy drives Message-Id: <2325@wasatch.utah.edu> References: <8610@batcomputer.tn.cornell.edu>, <1989Aug14.142109.1781@quintro.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1989Aug14.142109.1781@quintro.uucp> reb@quintro.UUCP (Roger E. Benz) writes: >In article <8610@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu (Moshe Braner) writes: >>Floppy drive: this is another backup option, and could also serve >>for easy Apollo (and the net) <--> IBM PC/AT file transfer. >>Can one get a 1.2 Meg 5.25" or a 1.44 Meg (or 720K) 3.5" drive? >>Can it read/write MS-DOS format files? Or only UNIX files? Both? >> > >Apollo has a floppy available that will meet your needs. It can read >write MS-DOS high dense floppies if you get the hardware or software >PC compatibility products. It does not read/write low dense floppies >very well. > >The cost, if you have a hard disk, is about $500 for the floppy. The PC >software emulator is about $500 and the PC hardware emulator is $2K-$3k. There is a program I wrote called PCdisk that supports high and low density MS-DOS floppy disks without the need for the Apollo software or hardware emulator. Its cost is less (and performance better) than the Apollo products: $200 for the first node and $100 for nodes after that. It can also support a 3.5" floppy, if want to add a non-standard drive to your node. (My DN4000 has a cartridge tape in the node and a 5.25" and 3.5" floppy in an auxiliary cabinet.) If you want more information, send me mail or write to: Contexture, Inc. PCdisk Information Post Office Box 58721 Salt Lake City UT 84158 From apollo-request@umix.cc.umich.edu Mon Aug 14 15:25:48 1989 Date: 14 Aug 89 17:11:40 GMT From: news%sics.se%sunic%mcvax.uucp@uunet.uu.net (Peter Olin) Organization: Swedish Institute of Computer Science, Kista Subject: ADUS Message-Id: <1989Aug14.171130.226@sics.se> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I've been looking through all my shelves of papers and documentation, but t looks as if I've lost the address to ADUS. Could someone please send me info about becoming a member. ---------------------------------------------------------------------- Peter Olin SICS, PO Box 1263, S-164 28 KISTA, SWEDEN Internet: olin@sics.se Tel: +46 8 752 15 57 From apollo-request@umix.cc.umich.edu Mon Aug 14 15:31:44 1989 Date: Mon, 14 Aug 89 13:50:49 CDT From: Andrew M. Wescott Message-Id: <8908141850.AA05242@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu, bemis_p@apollo.com, linell@apollo.com, oj@apollo.com, rubin_n@apollo.com Subject: Parallel Make on the dn10000 I have been playing with the dn10000 and several other parallel machines for awhile, and I have a nagging suggestion that I would like to make to those in Chelmsford involved with the Prism O/S and compilers. So here goes... We bought dsee.v.3.3.2.p for one reason: concurrent builds on a multiple cpu dn10000. I don't care about cross-compiled concurrent builds with our dn3500s that are coordinated with the dn10000s builds. I want to spawn concurrent builds across a multiple cpu dn10000. I have read all the dsee documentation, and you certainly do concurrent builds by replicating the node name of the dn10000 several times. I have to confess that dsee is an impressive piece of software, but its simply too sophisticated for most of our users. We have users that write large simulation codes that run on many parallel/vector UNIX or UNIX-like platforms. They don't want to be bothered with learning something like dsee on one platform. Okay, so what am I really asking for? Why not have a parallel UNIX make utility for multiple cpu dn10000s? As an example, consider the DYNIX O/S that Sequent runs on the Symmetry and other machines. The enhancements to Sequent's make include a " make -P [number of compile processes] " . If you have 20 cpus, and say 20 independent compiles to do within a makefile, then make -P20 will spawn off 20 compile processes. Now on a dn10000, you would probably only do make -P6 at most, but I think you can see my point. As an alternative to "make -P", you can set the environment variable PARALLEL to whatever value -p[] would have on the command line. Both the dn10000 and dsee are excellent products, but this just seems like the natural thing to do at the O/S level on a multiple cpu machine. Sincerely, Andrew M. Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Mon Aug 14 19:23:15 1989 Date: Mon, 14 Aug 89 17:10:09 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8908142110.AA00871@richter.mit.edu> To: apollo@umix.cc.umich.edu, news%sics.se%sunic%mcvax.uucp@uunet.uu.net Subject: Re: ADUS Apollo's ADUS co-ordinator is: Andrea Woloski Apollo Computer, Inc. 330 Billerica Road Chelmsford, MA 01824 You should be able to get an ADUS application form from your local sales office. Andrea can also be contacted via e-mail at woloski_a@apollo.com (it may be apollo.hp.com now) The ADUS office is pretty busy right now preparing for the annual conference in New Orleans. You may not get an immediate response. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Mon Aug 14 19:25:12 1989 Date: 14 Aug 89 17:51:45 GMT From: jim%eda.uucp@decwrl.dec.com (Jim Budler) Organization: EDA Systems, Inc. Santa Clara, CA Subject: Re: security hole Message-Id: <512@eda.com> References: <44e9d7d4.c4b0@apollo.HP.COM>, <511@eda.com>, <641@prles2.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu collins@nvpna1.prl.philips.nl (Donal O Coileain) writes: >In article <511@eda.com> jim@eda.com (Jim Budler) writes: >>From Apollo? >> >> Every month, an invoice arrives. (Well, not any more 8^) >Apollo produces a patch tape every month. In the 9.7 patch tape for JUNE 89 >months before this discussion was started I read : > "Patch 184 APR DCB34 : A security hole existed in the pad_$dm_cmd > .......................... > Now if the two user_ids are not equal, the command is disallowed and > the following error status is returned: > 'operation is illegal when no display is attached'" >You cannot blame Apollo because you don't read the release notes or >understand the bugs/fixes. Wanta bet? In two years of paying Apollo for support I did not receive ONE patch tape that I didn't have to ask about myself. I can't read the release notes if I don't get them. I call in a bug and get told "fixed in the XXXX patch tape", and that is frequently months old, as you mention. It doesn't do me any good to have Apollo produce a monthly patch tape if they never inform me of it's existance. You didn't read my posting very well or you would have realized that. You even quoted my statement that the only monthly mailings I got from Apollo were bills. >Donal O Coileain. collins@apolloway.prl.philips.nl or > collins%nvpna1.prl.philips.nl@uunet.uu.nl >-- And out of the gloom a voice said, 'Smile and be happy for things could > be a lot worse'. So I smiled and was happy and behold, things got worse -- jim -- Jim Budler address = uucp: ...!{decwrl,uunet}!eda!jim domain: jim@eda.com voice = +1 408 986-9585 fax = +1 408 748-1032 From apollo-request@umix.cc.umich.edu Wed Aug 16 13:27:31 1989 Date: 16 Aug 89 15:20:49 GMT From: turner%dover%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Robert Turner) Organization: Motorola, Inc., Semiconductor Products Sector Subject: Parallel Compile Timings on the DN10,000 Message-Id: <1679@dover.sps.mot.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu An answer to a question about parallel compiles on the DN10K an edited report DN10,000 and Gnu-make Timing information The DN10,000 compilers have the capability of compiling source programs for execution on the DN10,000 or 680x0 based equipment. This capability, referred to as cross compiling, was used to determine the effectiveness of using the DN10,000 as a "compile engine" for programs assigned to execute on 680x0 equipment. Gnu make is a free program from the Free Software Foundation. The source, available from UUNET, was down loaded and compiled for the Apollo under SR 10.1. Gnu-make is basically identical to the standard UNIX make with additional features. One interesting additional features is Gnu-make's ability to create multiple or parallel compiles. The user of Gnu-make specifies upon invocation of gnu-make the number of "job" to create in parallel. The follow timings document the compiling of the 21 modules, approximately 11,500 lines of "C" code, that make up Gnu-make. The data files for every compile resided on a DN3000. The timings are the wall clock time, in seconds, required to compiled, and link the program. The compile times on the DN10,000 are the times for creating an executable on a DN3000 class work station. parallel compiles DN3000 DN3500 DN10,000 DN10,000 Time in Seconds 358 234 109 41 Ratio 8.7 5.7 2.7 1.0 Robert From apollo-request@umix.cc.umich.edu Wed Aug 16 15:27:17 1989 Date: 16 Aug 89 16:11:20 GMT From: kcantrel%digi%attctc%vector%texbell%wuarchive%brutus.cs.uiuc.edu.uucp@tut.cis.ohio-state.edu (Keith Cantrell) Organization: DSC Communications, Plano Tx. Subject: Need help with rn/bnews on Apollos Message-Id: <203@digi.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I have run into a problem with running rn when rnews or rn is already running on a different machine. The problem is the first one will open the file "/usr/lib/news/active" for reading and therefore the Apollo operating system will lock it. After this has happens, I am unable to get a second rn or rnews to run on a different machine, the fopen complains "Text file busy". This problem does not exist if both programs are running on the same machine. This was a major problem when I started up rn on my machine and rnews was started up on a different machine and started loosing news since it could not open the active file :-( Has anybody else since this problem? It is easy to reproduce, just write a small program to open a file and executed it on two different machines and you will see the problem. Now for the particulars: Machines: DN3500 Operating system: BSD4.3-DOMAIN/OS News version: "B 2.11 1/24/89" I someone could please help me with this I would greatly appreciate it, Keith ----------------------------------------------------------------------- Keith Cantrell Phones: hm: 214-492-1088 wk: 214-519-2399 @ DSC USMAIL: EMAIL: 2100 Sonata Ln cantrell@attctc.DALLAS.TX.US Carrollton TX 75007 or ...!attctc!digi!kcantrel ----------------------------------------------------------------------- From apollo-request@umix.cc.umich.edu Wed Aug 16 17:25:21 1989 Date: 16 Aug 89 17:32:44 GMT From: anderson%spanky.sps.mot.com%dover%oakhill%cs.utexas.edu%csd4.csd.uwm.edu%gem.mps.ohio-state. Organization: Motorola, Inc., Semiconductor Products Sector Subject: Failure of tb after aqdev Message-Id: <1682@dover.sps.mot.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Refinement of information: Under release 10.1... While a device is acquired, any program failing in any pad fails to produce traceback data in /sys/node_data/system_logs/proc_dump. NOTHING is ever written to the proc_dump file while a device is acquired no matter what programs fail on the machine. In fact, if you delete the proc_dump file, while aqdev is in effect, you will see that no attempt is ever made to recreate it no matter what program signals are generated. (If the device is released and a program then fails, proc_dump is recreated immediately and contains proper information concerning the failure.) You can test this yourself. Do "ld -a /dev", look for "ddf" files. Here are some from our network: char ddf 2 2048 P prwx- dt2821 char ddf 2 2048 P prwx- dt2821F char ddf 2 2048 P prwx- dt2821G char ddf 2 2048 P prwx- dt2827 char ddf 2 2048 P prwx- dt2828 char ddf 2 2048 P prwx- pio_ddf char ddf 2 2048 P prwx- sio2_ddf char ddf 2 2048 P prwx- sio3_ddf char ddf 2 2048 P prwx- exatape0 Use aqdev to acquire one of the "ddf" files, i.e.: $ aqdev /dev/sio2_ddf Device 4 acquired. While acquired, you will see traceback and other debugging tools that depend upon sys/node_data/system_logs/proc_dump rendered useless. A ctrl z will release the device. $ *** EOF *** Device 4 released. Specific information regarding my node is: Domain/OS kernel(7), revision 10.1.1.2, April 4, 1989 5:22:10 pm NODE CONFIGURATION Node Type: DN3500 Display type: 1024 x 800 color display 68882 Floating Point Unit present. Peripheral configuration: Disks: winchester Networks: Ring Peripheral bus: AT-bus Tapes: none Disk types: MSD-380M -FA I have a Data Translation DT-2823 digitizer board and software that I wrote that never failed on release 9.7 but is failing occasionally under release 10.1. The board works fine. I get A/D and D/A conversion as before but something is failing when I take Fourier transforms of the data collected. The error is perhaps because of the new unix-like libraries that are more sensitive than the 9.7 Apollo libraries. (For example log(0) under 9.7 yields zero - under 10.1 log(0) yields "log: SING error" and, if you get enough of them, eventually aborts your program??) Anyway the dt2821 device must be acquired in order to run my program and the program aborts presumably due to the new unix-like libraries but it is difficult to debug since nothing is ever written to sys/node_data/system_logs/proc_dump while the device is acquired. Any ideas regarding how to get traceback data while a device is acquired will be greatly appreciated. Howard C. Anderson anderson@spanky.sps.mot.com From apollo-request@umix.cc.umich.edu Wed Aug 16 17:29:28 1989 Date: 16 Aug 89 20:47:38 GMT From: zeleznik%cs.utah.edu%wasatch%mailrus.uucp@tut.cis.ohio-state.edu (Mike Zeleznik) Organization: University of Utah CS Dept Subject: Registry unavailable on DN 10000 Message-Id: <2545@wasatch.utah.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have a 10000 and a 3500 on an ethernet, running one master and one slave registry (10.1 on both machines). ** A number of times each day, when trying to login in to the 10K, the system complains that the network registry is unavailable, and must use the local one. If we try a few times, it will eventually suceed. This happens if the 10K is running the master or the slave. Has anyone seen this? Are the registries locked up when the master/slave are resyncing? I can't see why they couldn't be at least readable. ** Also, does anyone (HP/Apollo?) know if there are plans to replicate the master registry? In a big net, it seems a bit much to expect the single master to be available in order to make any updates (or am I missing something). Thanks in advance, 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 Aug 16 19:25:49 1989 Date: Wed, 16 Aug 89 17:52:31 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8908162152.AA08528@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: SPE board wanted Does anyone have a used SPE board they want to sell? I'm looking for one (if the price is right, of course!). -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Wed Aug 16 21:23:49 1989 Date: 16 Aug 89 23:12:00 GMT From: conliffe%caen.engin.umich.edu%mailrus.uucp@tut.cis.ohio-state.edu (Darryl C. Conliffe) Organization: U of M Engineering, Ann Arbor, Mich. Subject: Controlling case of returned name from name_$get_path Message-Id: <45124af7.14df5@ulsoy.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu While using name_$get_path, I find the returned pathname is in all upper case letters. Does anyone know (1) why, and/or (2) how to get the pathname as it really exists? -- ___________________ Darryl C. Conliffe conliffe@caen.engin.umich.edu (313) 721-6069 ------------------- From apollo-request@umix.cc.umich.edu Wed Aug 16 21:30:11 1989 Date: 17 Aug 89 00:20:12 GMT From: majka%moose.cs.ubc.ca%ubc-cs.uucp@beaver.cs.washington.edu (Marc Majka) Organization: UBC Department of Computer Science, Vancouver, B.C., Canada Subject: Re: Registry unavailable on DN 10000 Message-Id: <4748@ubc-cs.UUCP> References: <2545@wasatch.utah.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Mike Zeleznik writes: >We have a 10000 and a 3500 on an ethernet, running one master and one >slave registry (10.1 on both machines). > >** A number of times each day, when trying to login in to the 10K, the >system complains that the network registry is unavailable, and must use the >local one. If we try a few times, it will eventually suceed. This happens >if the 10K is running the master or the slave. We currently have a DN10000, two 3500s, and a 4000. The DN10000 has the master registry. We have the same kind of trouble you describe, although things lock up about once a day for us. I had a slave registry running on one of the 3500s, and could cause the problem at will by just trying to look at the slave registry from the 10000. It seems to completely freeze NCS: the 3500 loses ALL communications with the outside world. Going down to a phase 2 shell (dm "ex" command), and restarting (")go") does not fix the problem. Only a complete shutdown and reboot gets things back to normal. In dispair, I killed off the slave registry, and stopped running the location broker daemons everywhere except on the 10000. The 3500s *still* freeze up daily. I reported my troubles to the hot line, but to no avail. I suspect that the problem is much deeper than the registries. I hope it is a bug in NCS (Network Crash System :-) on the DN10000, as I am about to install a network of 68 3500s and 3000s, and I will go insane if the same thing hits me there. SR10.1.p fixed a *lot* of bugs which were in 10.0.p. I suspect that there are still a bunch of them in 10.1. I understand that 10.2 will have a notion of "domains" which will allow different master registries on a network to co-exist. Has anyone seen it running yet? I would like to know how and if it works. We live on an extended ethernet which connects 3 universities and several research institutions. Having a single master registry on this network is an administrative impossibility. --- Marc Majka Computer Science System Manager, University of British Columbia From apollo-request@umix.cc.umich.edu Thu Aug 17 03:23:20 1989 Date: 16 Aug 89 15:26:55 GMT From: Chuck_SirVAX_Staatse%cup.portal.com%portal.uucp@uunet.uu.net Organization: The Portal System (TM) Subject: Signal Name Help Message-Id: <21343@cup.portal.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I need information concerning the pinouts and signal titles on the memory bus connector for the Apollo DN3000, DN3500, DN4000, and DN4500 workstations. Any information would be greatly appreciated. Please respond by mail. From apollo-request@umix.cc.umich.edu Thu Aug 17 03:27:12 1989 Date: 16 Aug 89 15:24:28 GMT From: Chuck_SirVAX_Staatse%cup.portal.com%portal.uucp@uunet.uu.net Organization: The Portal System (TM) Subject: Beta Testers Wanted Message-Id: <21342@cup.portal.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu From: JAY 16-AUG-1989 08:53 To: CHUCK Subj: DR-30/DR-40 BETA SITES !!!!! Wanted !!!!! Someone to Beta test memory boards for Apollo DN3000, DN3500, DN4000, and DN4500 workstations. What's in it for you? Determine if adding more memory to your system would show an improvement without having to buy it. If your system is memory bound, adding more memory should improve performance. Maybe your system is CPU or I/O bound. In this case, adding more memory would not improve the performance . . . Unless you are CPU and/or I/O bound because the system is doing excessive paging. The best way to determine how much improvement you will see by adding memory is to add the memory. In addition, the Sale department has said that beta testers will "earn valuable discount credits". I'm not sure what this means but it sounds like you might get a price break if you bought one later. What's in it for us? We get to verify the design and check out the installation instructions with more systems. Although the boards will have been extensively checked with our test equipment, there is nothing like real applications to prove out a design. We are also looking for valuable feedback on the ease of installation and clarity of the installation instructions. Who, What, Where, When and How: When: The time we have scheduled for Beta testing is September 25 through September 29 for the Apollo DN3500, DN4000, and DN4500 workstations. Beta testing for the Apollo DN3000 workstation is scheduled for October 10 through October 16. Where: We would like to do the testing in, or close to, New Jersey, eastern Pennsylvania, southeastern New York, Connecticut, Maryland, or Delaware. The Rest: If this sounds interesting, please leave mail with your name, address, phone number, and the best time to contact. OR Call Jay Scocchio at 609-799-0071 ext. 212. Monday-Friday 7:30 AM to 4:00 PM EDT We only need four beta sites. Once we have those sites, beta testing will be over. From apollo-request@umix.cc.umich.edu Thu Aug 17 05:25:04 1989 Date: 17 Aug 89 08:08:02 GMT From: usenet%agate.uucp@ucbvax.Berkeley.EDU (Partha S. Banerjee) Organization: University of California, Berkeley [Open Computing Facility] Subject: (gnu)bash for 35/4500s Message-Id: <1989Aug17.080802.10313@agate.berkeley.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Has someone out there ported most of the major gnu-utils to the Apollo 3500/4500 architectures? I am most immediately interested in bash ... the GNU (Boune Again) SHell. Is there a canonical (or even semi-canonical) distribution/exchange point for Apollo srcs and bins? We have a ~20 machine cluster here and have gotten most of the "software essential for computing as we know it" (emacs, x11, gcc) running reasonably well and would welcome colaboration/exchange/discussion/etc. While were at it, anyone have any advice on getting tcsh, tex, running? I'm also interested in any kind of ncs-oriented performance monitoring software people may have written ... graphical or text-oriented. --Partha S. Banerjee (Berkeley) Open Computing Facility From apollo-request@umix.cc.umich.edu Thu Aug 17 09:30:51 1989 Date: 16 Aug 89 08:04:40 GMT From: brett%spinifex%elecvax%usage%basser%metro%otc%munnari.oz.au%murtoa.cs.mu.oz.au.uucp@uunet. (Brett Sealey) Organization: Kenso Kindi (UNSW) Subject: Problems with Domain 2D-GMR header file. Message-Id: <414@spinifex.eecs.unsw.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I'm using the Domain 2D Graphics Metafile Resource package, and have noticed that some of the function prototypes in the file gmr.h seem to be inconsistent with the types of parameters actually being past. In particular, functions which use 'array-type' parameters are the ones which seem to be causing problems. I am using 2D-GMR version 2.1 under both C and C++. Examples: ~~~~~~~~~ >From base.h:- typedef char name_$pname_t[name_$pnamlen_max]; >From gmr.h:- extern void gm_$file_create( name_$pname_t &name, ... extern void gm_$segment_inq_current( name_$pname_t *name, ... It's the `*' and `&' symbols which seem to me to be unnecessary and which are causing me problems. Any comments are welcome, as it is I have already hacked a copy of gmr.h myself as a short term fix. Thanks, Brett Sealey. (brett@spinifex.eecs.unsw.oz) From apollo-request@umix.cc.umich.edu Thu Aug 17 13:33:55 1989 Date: 17 Aug 89 16:24:06 GMT From: sarathy%utgpu%jarvis.csri.toronto.edu%mailrus.uucp@tut.cis.ohio-state.edu (Rajiv Sarathy) Organization: University of Toronto Computing Services Subject: Re: Creating a window on a remote node Message-Id: <1989Aug17.083649.3654@gpu.utcs.utoronto.ca> References: <492@calmasd.Prime.COM>, <44ed8514.ce45@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <44ed8514.ce45@apollo.HP.COM> gaz@apollo.HP.COM (Gary Zaidenweber) writes: >From article <492@calmasd.Prime.COM>, by sas@calmasd.Prime.COM (Shirley Sloper): >> >> Messages from long ago.... >>> Someone writes: >>>>From: "ANIMAL::THOMPSON" >>>>Subject: Re: Placing a window on another node. >>>> But. back to the question at hand. >>>> [Great info on how to creat a pad on another node via send_alarm or >>>> crp/crpad] >>>> >>>>John Thompson >>> >>>Either way (send_alarm, crp/crpad, /bin/write, or /bin/wall), you can't >>> [blah, blah, blah.....] >> >> >> Hello, >> >> Does anyone remember the above discussion? (I'm sorry the references >> aren't there, this is all I can find.) I had just started reading the >> group (June?) and I believe the main discussion may have been concerning >> borrow mode. I'm not interested in borrow mode, what I would like is >> the "great info on how to create a pad on another node...", that the >> message refers to. Can someone inform me how to do this? >> >> This is the situation I am dealing with: A process on node A starts a >> process (CPS) on node B. I want the node B process to be able to >> inform node A that it is finishing, (either from a shell script or C >> module). Most probably, the originating process on A is no longer >> running. What I would like to do is create a window back on node A. >> >> Thankyou, thankyou, thankyou! >> >> >> -- >> Shirley A. Sloper sas@calmasd.prime.com >> ****** Calma ****** >> ** 9805 Scranton Road ** >> ** San Diego, CA 92121 ** > >The following module sort of emulates the system() call, creating >a window to run the shell. It runs under sr10.1+ (and maybe 10.0 >I just haven't tried and don't expect to). I run in a sysV environment >but I know this works in Aegis and BSD too. I believe that it will >not run under sr9.7 without modifications.: > >#include >#include > [long c program] Why can't you just do this: crp "/com/crpad " -on // -me This will place the contents of in a read-only window on // -- _____________________________________________________________________________ | Disclaimer: I'm just an undergrad. All views and opinions are therefore _ | | my own. /\ /\ /-----------------------------------oO(_)| | / \ / \ / NetNorth: sarathy@utorgpu | | Rajiv Partha Sarathy / \/ \/ sarathy@gpu.utcs.utoronto.ca | | --------------------/ {uunet!attcan mnetor att pyramid}!utgpu!sarathy | |_____________________________________________________________________________| From apollo-request@umix.cc.umich.edu Thu Aug 17 15:29:04 1989 Message-Id: <8908171754.AA10295@umix.cc.umich.edu> Date: Thu, 17 Aug 89 13:50 EDT From: FERGUSON%TMASL.EXXON.COM@CUNYVM.CUNY.EDU Subject: name_$get_path and case-correctness To: apollo@umix.cc.umich.edu X-Vms-To: APOLLO If you look in the name.ins.x file, you'll find a few calls added by Nat Mishkin, with a suffix of _cc (for 'correct case'). These calls have exactly the same arguments, they just return things in the proper case. Therefore, name_$get_path_cc is the call for you to use. Scott Ferguson From apollo-request@umix.cc.umich.edu Thu Aug 17 17:28:27 1989 Date: 17 Aug 89 19:11:32 GMT From: rich@eddie.mit.edu (Richard Caloggero) Organization: MIT EE/CS Computer Facility, Cambridge, MA Subject: ptys & rlogin Message-Id: <12461@eddie.MIT.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I have a program that uses ptys to communicate with its child. If its child is local to this host, everythings ok. If its child is rlogin, and then an emt is started on the remote node, characters are dropped. All is fine on the remote node till emt is invoked. If emt is in local mode, all is still fine; as soon as the remote host starts sending stuff, however, characters start disappearing. It looks like a flow-control problem, but I'm not sure of this. I didn't use any fancy pty modes. Any guesses as to who is eating my characters? :-) [ Please mail responses to me (rich@eddie.mit.edu)! ] -- -- 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 Thu Aug 17 23:38:34 1989 Date: 16 Aug 89 21:36:53 GMT From: rhaslam%esunix%uplherc%wasatch%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Reed Haslam) Organization: Evans & Sutherland, Salt Lake City, Utah Subject: Used Apollo Equipment Dealers Message-Id: <1439@esunix.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have some Apollo DN 4000 series workstations (4000,4500) that we need to dispose of. If anyone knows of used Apollo equipment dealers I'd appreciate receiving such information. Reed B. Haslam Evans & Sutherland Computer Corporation 600 Komas Drive Salt Lake City, Utah 84108 (801)-582-5847 x3344 {decwrl ! utah-cs}!esunix!rhaslam From apollo-request@umix.cc.umich.edu Fri Aug 18 05:31:48 1989 Message-Id: <8908180858.AA04835@umix.cc.umich.edu> Date: Fri, 18 Aug 89 16:55:04 SST From: fclim Subject: Re: Accounting ? To: One ADU to another Can someone help Michal? I sez that the sys-admin need not install the BSD environment (when he's installing SR10) to have the /etc/accton facility. Because I have not install SR10, I'm not sure why Michal couldn't find /etc/accton. --------------- Original Message -------------------------------------- From: Merlin The Magician Subject: RE: Accounting ? To: gbopoly1@NUSVM.BITNET X-VMS-To: in%"gbopoly1@nusvm.bitnet" X-VMS-News: kuhub.cc.ukans.edu comp.sys.apollo:1765 > From: GBOPOLY1@NUSVM.BITNET (fclim) > Subject:RE: Accounting ? > Date: 14 Aug 89 09:33:46 GMT > Message-ID:<8908140934.AA18876@umix.cc.umich.edu> > > I don't know whether Apollo Domain/OS (ie SR10+) has disk quota or > disk usage accounting, but you can switch on process accounting via > "/etc/accton". This command is documented in the "Managing your > BSD software" manual for sys-admins. The man page is in Section 8 > and listed under (surprising) /etc/sa. > > You *don't* need to install the BSD environment to > have the accounting facility. Well, there does not seem to be anything like /etc/accton. I came across a three-program accounting env. You have one process sitting in the background and collecting info every X sec. Ther other program signals new users on the system and when users log off. The program was written by Scott (..) from Apollo. The program is unsupported. Is that you have meant by /etc/accton. ? Furthermore, running the above mentioned program couses a 20 fold slowdown, not an acceptable trade-off. Well, I'll look around for the /etc/accton but no clue as to where it can be. Thanks for you input. -Merlin -- +------------------------------+----------------------------------------------+ | Michal Chmielewski \ The inherent vice of capitalism is the | | Academic Computing Services \ unequal sharing of blessings; the | | University of Kansas \ inherent virtue of socialism is the | | Lawrence, KS 66045 \ equal sharing of miseries. | | Internet: michal@kuhub.cc.ukans.edu - Winston Churchill | | BitNet : michal@ukanvax.bitnet \ | +-------------------------------------+---------------------------------------+ ---------- End of Original Message ------------------------------------ fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Add your pet peeve If we think really hard, maybe we can stop this ____! No ____! No ____! No ____! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From apollo-request@umix.cc.umich.edu Fri Aug 18 05:32:45 1989 Message-Id: <8908180902.AA04949@umix.cc.umich.edu> Date: Fri, 18 Aug 89 16:57:05 SST From: fclim Subject: Re: question about path setup under sr10.1/bsd4.3 To: One ADU to another In article <8908140932.AA18839@umix.cc.umich.edu> I wrote > In article <44d047e0.1b147@apollo.HP.COM> nazgul%apollo%ulowell% > mailrus.uucp@ames.arc.nasa.gov (Kee Hinckley) writes: > > > In article <13400@netnews.upenn.edu> lau@kings.wharton.upenn.edu > > (Yan K. Lau) writes: > > > How does one change the default path of users when they log > > > into a node or create a shell under SR10.1/BSD4.3? > > > We have both Aegis and Unix running. Some users use the > > > C shell or Bourne shell and others use the Aegis shell. > > > > In the Bourne and Korn shells you can do it by changing > > /etc/profile and /etc/profile.ksh. Neither the C shell or > > the Com shell have means of doing this, however with the > > Com shell you could try (I don't guarantee this though > > since at login the shell might ignore it) setting the > > environment variable "CSR" in the DM login scripts. > > Otherwise the best way is to simply install a > > default .login or $HOME/user_data/sh/login script for > > every user. > > In the book "The Unix C Shell Field Guide" by Gail and Paul Anderson, > (Prentice-Hall publisher; ISBN: 0-13-937468-X 025), on page 354, > the authors write that C shell execute the file > /etc/cshrc (or /etc/cshprofile) before going on to ~/.cshrc. > This is not implemented in the SR9- nor SR10+ C shells. HP/Apollo: > why? How about adding it to SR11? I have been informed that the csh of SR10.2 looks up /etc/cshrc. > If you hide such information from them (especially novices), they > might use Aegis commands with wild-cards in a Unix shell. This may > lead to disastrous results: > > > From: reesd%gtephx%hrc%asuvax.uucp@handies.ucar.edu (David Rees) > > Subject: Re: Aliases For Aegis Commands > > Message-Id: <44c14aa1.f9df@gtephx.UUCP> > > > > First of all you must be carefull when making aliases for aegis > > to unix or the other way around. For instance I tried to make an > > alias for cpf: > > %alias cp cpf > > > > This is WRONG! First of all cpf does all its copying in pairs while > > cp copies all the items to the last item. > > > > $cpf F1 F2 F3 F4 > > F1 -> F2 (F1 is copied to F2) > > F3 -> F4 (F3 is copied to F4) > > > > %cp F1 F2 F3 F4/ > > F1 F2 F3 -> F4 (They are copied into F4) > > > > And second of all with the Unix shells (Bourne and C) the regular > > expressions are expanded by the shell, while in Aegis it seems like > > the expressions are expanded by the command. For instance I typed > > the following: > > > > %cpf ?*.c ./backup -r <--- DON'T DO THIS! > > > > While this is right out of the manual I missed a critical detail. > > The '%' > > instead of the '$'. Since the C shell expanded the wildcard first, > > it sent > > cpf a list of the files and then cpf proceeded to replace every othe > > file (about three weeks worth of work, thank god for backups). > > > > -David I have also been informed that Aegis commands like cpf and mvf have a new option -p. I was not informed of what this option does and whether the option is available at SR10.1 or if we have to wait for 10.2. All sys-admins oughta look up the -p option in the man pages and inform all their users who use Aegis commands in a Unix shell. fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Add your pet peeve If we think really hard, maybe we can stop this ____! No ____! No ____! No ____! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From apollo-request@umix.cc.umich.edu Fri Aug 18 07:26:29 1989 Date: 18 Aug 89 04:04:13 GMT From: danny%idacom%alberta%ubc-cs.uucp@beaver.cs.washington.edu (Danny Wilson) Organization: IDACOM Electronics Ltd., Edmonton, Alta. Subject: Apple Connectivity Message-Id: <717@idacom.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am looking for a software and/or hardware product that will allow me to connect a MAC to an Apollo (either via sio, ethernet or otherwise). My primary object is to be able to spool print files of the mac to an Imagen printer running off of the Apollo. The imagen is driven by a Mentor Graphics print server running on an apollo node. Anyone out there have any experience and/or recommendations concerning this stuff? Please e-mail your comments directly and I will post a summary in two weeks. Thanks -- Danny Wilson IDACOM Electronics danny@idacom.uucp Edmonton, Alberta {att, watmath, ubc-cs}!alberta!idacom!danny C A N A D A From apollo-request@umix.cc.umich.edu Fri Aug 18 07:32:27 1989 Date: 11 Aug 89 16:35:03 GMT From: dente%els%mucs%ukc%mcvax.uucp@uunet.uu.net (Colin Dente) Organization: University of Manchester, UK Subject: Re: security hole Message-Id: <6452@ux.cs.man.ac.uk> References: <44e9d7d4.c4b0@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <44e9d7d4.c4b0@apollo.HP.COM> dawson@apollo.HP.COM (Keith Dawson) writes: >In a recent posting Peter Lipp [plipp@tugiig.uucp] details a > > Possible Security Problem with DOMAIN-OS and the Display-Manager >[Gives patch numbers for 9.7 and 10.1] >These patches can be applied to /lib/streams on any version of SR9.7 >and SR10.1, including the versions that support Domain/X11. Please ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Well, I 'phoned my local support office, and they told me that the release notes for the 9.7 patch (they haven't got the 10.1 patch yet) state that it should *not* be applied if you are running Domain/X11. Naturally, I was a bit miffed at this - so I 'phoned Keith to see what he had to say. He seemed to think that the patch was, infact, more than one patch in one bundle, and if I applied just the /lib/streams part, I'd be okay. Anyway, I'm waiting for a floppy to land on my doormat with the patch on it, and when it does, I'll try it and let you know. Just thought I'd try to clear the confusion in the meantime. >We regret the broad dissemination of detailed instructions for exploiting >a security hole. So do I...... |-( Colin =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | 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 Fri Aug 18 09:27:49 1989 Date: 18 Aug 89 05:37:27 GMT From: scott%labtam%munnari.oz.au%murtoa.cs.mu.oz.au.uucp@uunet.uu.net (Scott Colwell) Organization: Labtam Limited., Melbourne, Australia Subject: 3rd part disks for Apollo DN3000s and DN3500s Message-Id: <1753@labtam.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Sorry if this topic has been thrashed to death, but some help would be appreciated. We are interested in putting second and/or larger drives into our Apollo workstations. It appears that it is not possible to put 2nd drives onto them because the OS plus the utilities can't cope. Can anyone either confirm or deny this ? We currently run SR9.7.1 but will be going to SR10 in the next 2-3 weeks. (The actual hardware is no problem since the controllers can take two drives.) Has anyone had experience putting a larger drive into one of these machines ? Do we have to restrict ourselves to one of the drives on the list of drives shown when running 'config' ? Any help or relevant stories would be appreciated. -- Scott Colwell ACSnet: scott@labtam.oz Senior Design Engineer UUCP: ..uunet!munnari!labtam.oz!scott Labtam Information Systems P/L ARPA: scott%labtam.oz@UUNET.UU.NET Melbourne, Australia PHONE: +61-3-587-1444 From apollo-request@umix.cc.umich.edu Fri Aug 18 11:28:33 1989 Date: Fri, 18 Aug 89 09:10:39 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8908181310.AA11997@richter.mit.edu> To: rhaslam%esunix%uplherc%wasatch%cs.utexas.edu.uucp@tut.cis.ohio-state.edu Subject: Re: Used Apollo Equipment Dealers Cc: apollo@umix.cc.umich.edu I know of two dealers/brokers that I can give you info about: IMPAK 415-651-7373 Computer Locators 407-777-9924 From apollo-request@umix.cc.umich.edu Fri Aug 18 13:30:43 1989 Date: 18 Aug 89 15:08:01 GMT From: dennis%peanuts.nosc.mil.uucp@nosc.mil (Dennis Cottel) Subject: /usr/ucb/Mail bug remains under SR10 Message-Id: <1417@nosc.NOSC.MIL> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Out of curiosity, I sat down this morning and executed /usr/ucb/Mail on our experimental SR10.1 node. I was dismayed to find that when you use the ~h excape to modify the header fields, the previous contents of the fields are discarded. This bug has been on the known bug list at Apollo for years! I can't believe that after all the changes to make SR10 "real UNIX", including rewriting the input streams to provide "real ttys", that this hasn't been fixed. I dunno, I guess I just naively expected that in return for all the hassle we users were going to have to go through in converting to the new OS, Apollo would provide improvements and repairs for all the little outstanding glitches that were there because they didn't have a real UNIX capability. 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 Fri Aug 18 15:25:37 1989 Message-Id: <8908181723.AA14796@umix.cc.umich.edu> Date: Fri, 18 Aug 89 13:18 EDT From: FERGUSON%TMASL.EXXON.COM@CUNYVM.CUNY.EDU Subject: gpr_$text and Raster ops To: apollo@umix.cc.umich.edu X-Vms-To: APOLLO Why is it that gpr_$text ignores the Raster OP? How does one rubberband text without having to BLT to memory and back? I think I might've noticed once that gpr_$rectangle ignores ROP's also. Any insights into why some primitives ignore raster ops? Any reason why they should? I'm at 9.7, so if "it's fixed in sr10", I guess I'll have to live with it. (see my next message) Scott Ferguson ferguson@erevax.bitnet Exxon Research & Engineering (201)730-2339 From apollo-request@umix.cc.umich.edu Fri Aug 18 15:31:08 1989 Message-Id: <8908181731.AA15625@umix.cc.umich.edu> Date: Fri, 18 Aug 89 13:28 EDT From: FERGUSON%TMASL.EXXON.COM@CUNYVM.CUNY.EDU Subject: OS Updates and Solution Suppliers To: apollo@umix.cc.umich.edu X-Vms-To: APOLLO Ever since I began administering Apollos, I've been plagued by a problem outside of Apollo: Whenever Apollo makes these radical OS changes, there's a HUGE (capital H) time lag before the third party software/peripheral vendors bother to come out with a new revision of their support software. For instance: Mercury Computer Systems MC3232 Array processor, driver software for SR10 is nowhere in sight. Real-Time Enterprises Optical Disk File Manager: No sr10 drivers. Way back when: Graftek CAD Software wasn't ready for sr9.5 for many months. I've heard they're not ready for sr10 yet either. In fact, they just released an update that only works on 9.7 recently. The list continues, but that's not the point. Now, I've received driver software from Apollo for a Tektronix 4693 printer, and it's all set up with RAI installation procedures. I can't install this software until I update to sr10. I CAN'T update to sr10 until the third parties get in gear, and support their customers. Is there anything that Apollo/HP or us users as a group can do to put more pressure on Solution suppliers to keep up with the pace of the OS updates? I mean, I know that re-working software for new OS revisions is a hassle, but I've always found new features in the OS that the software could take advantage of, and the effort has always been worthwhile. Plus, NOT keeping up puts us users in a tight spot about a year after the Apollo revisions come out. I'm assuming in the future that Apollo won't need to cause such major waves like 9.2->9.5 and 9.7->10, but then again... Scott Ferguson ferguson@erevax.bitnet (201)730-2339 Exxon Research & Engineering Annandale, NJ 08801 From apollo-request@umix.cc.umich.edu Fri Aug 18 15:32:50 1989 Message-Id: <8908181841.AA20996@umix.cc.umich.edu> Date: 18 Aug 89 13:37:00 CST From: "DAVE ERSTAD" Subject: Case control To: "apollo" Darryl Conliffe asked about controlling case of returned paths from name_$get_path. Yes, that always returns upper case. Solution: At SR9.7 use "call_cc" (e.g. name_$get_path_cc) to get case correct paths. This will also work at SR10. However, Apollo plans to obsolete these, or so their release notes claim. The call to use at SR10 is call_lc (e.g. name_$get_path_lc). From apollo-request@umix.cc.umich.edu Fri Aug 18 15:35:06 1989 Date: Fri, 18 Aug 89 14:59:34 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8908181859.AA13024@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: shopping list I'm looking to purchase the following ;pieces of equipment: 1) Apollo SPE serial/parallel expansion board 2) Ikon 10092 printer interface board 3) Floor stand for a DN3000/4000 If you are trying to get rid of one or more of these items, give me a call. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) (617)253-6180 From apollo-request@umix.cc.umich.edu Fri Aug 18 17:21:31 1989 Date: 18 Aug 89 19:19:06 GMT From: dennis%peanuts.nosc.mil.uucp@nosc.mil (Dennis Cottel) Subject: Re: /usr/ucb/Mail bug remains under SR10 Message-Id: <1418@nosc.NOSC.MIL> References: <1417@nosc.NOSC.MIL> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu This morning I wrote: > Out of curiosity, I sat down this morning and executed /usr/ucb/Mail on > our experimental SR10.1 node. I was dismayed to find that when you use > the ~h excape to modify the header fields, the previous contents of the > fields are discarded. This bug has been on the known bug list at > Apollo for years! I can't believe ... > ...[further whining deleted] It has just been pointed out to me that the node on which I did this test is not completely set up properly, and the version of Mail I tested was in fact the SR9.7 one. I found the SR10.1 version of Mail and tried it -- it works fine; the bug is fixed. My apologies for the misinformation. 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 Fri Aug 18 17:26:46 1989 Date: 18 Aug 89 18:42:11 GMT From: lau%kings.wharton.upenn.edu%netnews.upenn.edu%eecae%tank.uucp@handies.ucar.edu (Yan K. Lau) Organization: desci Subject: Re: /usr/ucb/Mail bug remains under SR10 Message-Id: <13780@netnews.upenn.edu> References: <1417@nosc.NOSC.MIL> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1417@nosc.NOSC.MIL> dennis@peanuts.nosc.mil (Dennis Cottel) writes: >Out of curiosity, I sat down this morning and executed /usr/ucb/Mail on >our experimental SR10.1 node. I was dismayed to find that when you use >the ~h excape to modify the header fields, the previous contents of the >fields are discarded. This bug has been on the known bug list at [mild flame delete] > > Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152 > (619) 553-1645 dennis@nosc.MIL sdcsvax!noscvax!dennis Actually, I've never used the ~h command. Do you use it when you send a message? I wouldn't call myself a Unix expert but when I tried this, it did show my previous values. Am I missing something? Yan. --- Yan K. Lau + the last message of a newgroup will be: )~ + a) longer than one screen & ~/~ lau@scrolls.wharton.upenn.edu + b) something you're not interested in. /\ University of Pennsylvania + your decision, 'n' key or space bar? From apollo-request@umix.cc.umich.edu Fri Aug 18 23:17:46 1989 Date: Fri, 18 Aug 89 21:42:53 CDT From: Andrew M. Wescott Message-Id: <8908190242.AA09613@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu Subject: dn10000 registry unavailable, etc .... Well I have been out of town awhile, so this may have been resolved privately.... All the problems with dn10000s and dn3500s, dn4000s on a net with registries running on both machine types I have seen before. I will be willing to bet my last dollar that if you delete /sys/ethernet8_microcode on your 3500/4000/4500 machines running SR 10.1, all your problems will go away. If I still have my dollar left after you try this, I'm rather %&@!!! I have told countless people about this, but why doesn't anyone from Chelmsford tell people about this. It seems like nobody at 1-800 knows about this. Actually, that's not quite true because there really is a patch for this, but it seems that the right people don't know about it. I normally don't like to rag on Apollo, but let me just suggest that alot of the gab on the net about REALLY sending customer bug reports, patch lists, etc. should really be taken seriously. Alot of people have sweated days, not hours over this bug. That shouldn't have happened. Sincerely, Andrew Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Mon Aug 21 01:20:51 1989 Date: 10 Aug 89 15:08:33 GMT From: greg%apcitor%ncrcan%attcan%utgpu%jarvis.csri.toronto.edu.uucp@rutgers.edu (Greg Foisy) Organization: apollo computer (canada) ltd. Subject: Re: dn10000 registry unavailable, etc .... Message-Id: <419@apcitor.tor.apollo.com> References: <8908190242.AA09613@lnic1.hprc.uh.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8908190242.AA09613@lnic1.hprc.uh.edu> wescott@LNIC1.HPRC.UH.EDU (Andrew M. Wescott) writes: >I will be willing to bet my last dollar that if you delete >/sys/ethernet8_microcode on your 3500/4000/4500 machines running >SR 10.1, all your problems will go away. Sorry to take all of your money like this, but there is a problem with the O/S on the DN10000 that will cause the registries to go away for a while, usually about 20 minutes and then come back. The problem has been corrected and there is a patch tape for the DN10000 with a new domain_os and domain_os.map on the tape. You can get the tape from your normal channels. > >If I still have my dollar left after you try this, I'm rather %&@!!! There is also a problem with the /sys/ethernet8_microcode as stated above, However you will most likely only run into the problem if you are running both DN3000/DN4000 and DN10000's in the same network. There is a patch available for this problem as well > >I normally don't like to rag on Apollo, but let me just suggest >that alot of the gab on the net about REALLY sending customer >bug reports, patch lists, etc. should really be taken seriously. >Alot of people have sweated days, not hours over this bug. >That shouldn't have happened. > Could people on the net please send me some e-mail and let me know if it is worth their while if I post the index for the patch tapes once a month so that people could se what patches are availble. This is not per say my responsibility at apollo, however, I feel it might be helpful to those on the net if they were more aware of the patches that could be obtained. Greg Foisy Disclaimer so that I don't get kick too hard for this... Of course, these views are mine and mine only. They do not in any way reflect the thoughts of apollo, Hewlett-Packard, or management. -- One of the most overlooked advantages to computers is... If they do foul up, there's no law against whacking them around a little. - PORTERFIELD (Joe Martin) apollo computer, a workstation division of Hewlett-Packard +-------------------------------------------------------+---------------------+ | UUCP: {yunexus lsuc ncrcan ontenv apcihq}!apcitor!greg| Greg Foisy | | INTERNET: greg@tor.apollo.com | apollo (canada) ltd.| | CANPOST: 1530 Markham Road, Suite 130, Scarborough | (416) 297-0700 | +-------------------------------------------------------+---------------------+ From apollo-request@umix.cc.umich.edu Mon Aug 21 17:25:28 1989 Date: 21 Aug 89 19:41:07 GMT From: ins_bxl%jhunix%aplcen%ginosko%gem.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu (Xuyong Liu) Organization: The Johns Hopkins University - HCF Subject: Re: Accounting ? Message-Id: <2338@jhunix.HCF.JHU.EDU> References: <8908180858.AA04835@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8908180858.AA04835@umix.cc.umich.edu> GBOPOLY1@NUSVM.BITNET (fclim) writes: >Can someone help Michal? I sez that the sys-admin need not install >the BSD environment (when he's installing SR10) to have the /etc/accton >facility. Because I have not install SR10, I'm not sure why Michal >couldn't find /etc/accton. > We installed complete BSD4.3 environment of SR10.1, and the accounting facility came with the standard Apollo release. The related executibles are /bsd4.3/etc/accton and /bsd4.3/etc/sa. I am not sure if you have to install BSD environment to get those facilities. -------- liu@alpha.ece.jhu.edu ins_bxl@jhunix.UUCP From apollo-request@umix.cc.umich.edu Mon Aug 21 19:18:55 1989 Date: 21 Aug 89 21:14:58 GMT From: cdaf@iuvax.cs.indiana.edu (Charles Daffinger) Organization: Indiana University, Bloomington Subject: Question to those who repair their own... Message-Id: <24834@iuvax.cs.indiana.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I have a DN550 with a Power Components main power supply. The MOV (in location R1) just blew out on it, and I can't read the component number off of the ashes. If anyone has replaced this part, could you let me know what the replacement is? No, I don't have a service contract ;-). Thanks, -charles -- Charles Daffinger >Take me to the river, Drop me in the water< (812) 339-7354 cdaf@iuvax.cs.indiana.edu {pur-ee,rutgers,pyramid,ames}!iuvax!cdaf Home of the Whitewater mailing list: whitewater-request@iuvax.cs.indiana.edu From apollo-request@umix.cc.umich.edu Tue Aug 22 03:20:46 1989 Date: 22 Aug 89 06:08:35 GMT From: lnz%lucid.com%polya%shelby%agate.uucp@ucbvax.Berkeley.EDU (Leonard Zubkoff) Organization: Lucid, Inc. Menlo Park, CA Subject: screen2 Message-Id: <2131@heavens-gate.lucid.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu A few weeks ago there was a brief discussion of a program called screen2 that provided vt100 emulation along with other facilities. Can anyone point me to a source for this program? Thanks. Leonard From apollo-request@umix.cc.umich.edu Tue Aug 22 09:19:52 1989 Return-Path: hanyak%garnet.bucknell.edu@CORNELLC.cit.cornell.edu Message-Id: <8908221350.AA00203@apollo.bucknell.edu> 09:50:56 edt Date: Tue, 22 Aug 89 09:50:56 edt From: "M.E. Hanyak" Subject: Re: screen2 To: apollo@umix.cc.umich.EDU, lnz%lucid.com%polya%shelby%agate.uucp@ucbvax.BERKELEY.EDU Here is a copy of that original discussion: Date: Sat, 24 Jun 89 17:19:02 CDT From: "Andrew M. Wescott" Subject: Screen Terminal Manager To: apollo@umix.cc.umich.EDU Message-Id: <8906242219.AA08246@lnic1.hprc.uh.edu> Status: R I have recently come across a PD product known as Screen that some of you may be familiar with. Screen is a window manager for remote terminals that lets users have multiple sessions from a vt100 through the use of pseudo terminals. With a simple control command you can flip back and forth between several full-screen windows. Specifically Screen provides: 1.) Complete ANSI VT100 emulation. Kiss all those TERM and stty problems with remote sessions good-bye. 2.) Multiple full-screen windows 3.) The ^s problem with a VT100 using GnuEmacs is solved. These are all probelms I have had to deal with. We are running Screen 1.0, and it compiled with very little work. Screen 2.0 provides some NFS support, and it gave me some problems at run time (but I didn't really try that hard). The program was written by Oliver Laumann with modifications by Peter Wolfe at Kuch & Assoc. I highly recommend it. You can download the source from netlib@mcs.anl.gov. I will try to help anyone interested. Andrew Wescott University of Houston Department of Chemical Engineering Date: 25 Jun 89 15:12:36 GMT From: kts%quintro%tiamat.uucp@uunet.uu.NET Subject: Re: Screen Terminal Manager Sender: apollo-request@umix.cc.umich.EDU To: apollo@umix.cc.umich.EDU References: <8906242219.AA08246@lnic1.hprc.uh.edu> Organization: none Message-Id: <362@quintro.UUCP> Status: R In article <8906242219.AA08246@lnic1.hprc.uh.edu> wescott@LNIC1.HPRC.UH.EDU (Andrew M. Wescott) writes: > >I have recently come across a PD product known as Screen >that some of you may be familiar with. Screen is a window >manager for remote terminals that lets users have multiple >sessions from a vt100 through the use of pseudo terminals. >With a simple control command you can flip back and forth >between several full-screen windows. Specifically Screen >provides: > Screen is a great program. I've been running screen 2.0 for a couple months and haven't had any problems at all. Screen 1.0 and 2.0 are very similar, the only useful difference I've noticed is at 2.0 you can "detach" a session from the terminal, logout, come back later and "re-attach" the session. One warning: you MUST be running 10.1 to use screen. Screen uses TCP/IP pseudo-ttys for each window and the pre-10.1 TCP/IP release has problems doing some types of i/o with ptys. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ken Smelcer Quintron Corp. quintro!kts@lll-winken Quincy, IL tiamat!quintro!kts@uunet Mike Hanyak Chem. Eng. Dept. Bucknell University Lewisburg, Pa 17837 From apollo-request@umix.cc.umich.edu Tue Aug 22 11:19:39 1989 Date: 22 Aug 89 13:01:00 GMT From: mishkin%apollo.uucp@EDDIE.MIT.EDU (Nathaniel Mishkin) Organization: Apollo Computer, Chelmsford, MA Subject: Re: Controlling case of returned name from name_$get_path Message-Id: <452e55a9.1d6d5@apollo.HP.COM> References: <45124af7.14df5@ulsoy.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <45124af7.14df5@ulsoy.engin.umich.edu> conliffe@caen.engin.umich.edu (Darryl C. Conliffe) writes: >While using name_$get_path, I find the returned pathname >is in all upper case letters. Does anyone know (1) why, >and/or (2) how to get the pathname as it really exists? Contrary to a previous, almost correct followup to this posting, the correct call to use is "name_$get_path_lc", not "name_$get_path_cc". "name_$get_path_cc" (actually all the "_cc" calls) exist only for historical reasons -- they got put out before we realized that we really wanted all the name-returning calls to take an input parameter that specifies the actual length of the caller's output buffer. BTW, the reason that "name_$get_path" (in fact all the very old name-returning calls) didn't start returning mixed-case names at sr10 was because we were concerned about programs that did things like: name_$get_path(...); if (...last 4 chars of returned path is ".TXT"...) { ... } Note that the program would be checking for ".TXT" and not ".txt". Of course, some other program might use the returned pathname as *input* to some call that takes a pathname and then *that* call will fail because the file's name is "foo" not "FOO". Basically, someone loses either way. However, the DOWNCASE hack can sort of accomodate the latter class of program so we decided to not break the former class of program. -- -- Nat Mishkin Apollo Computer Inc., Chelmsford, MA mishkin@apollo.com From apollo-request@umix.cc.umich.edu Tue Aug 22 17:57:37 1989 Message-Id: <8908222029.AA13624@umix.cc.umich.edu> Date: 22 Aug 89 15:16:00 CST From: "DAVE ERSTAD" Subject: Re: Controlling case of returned names from name_$get_path To: "apollo" > Contrary to a previous, almost correct follup to this posting > the correct call to use is name_$get_path_lc, not name_$get_path_cc No, much as I hate to contradict a resident Apollo Wizard, the originally presented info is correct. At SR9.7 the _lc calls do not exist in the standard released insert files nor in the run-time libraries. Thus, one must use _cc for programs which execute under 9.7 or a mixed 9.7/10.0 environment. From apollo-request@umix.cc.umich.edu Tue Aug 22 19:56:57 1989 Date: 22 Aug 89 21:54:43 GMT From: roode%hydra.cf.uci.edu%orion.cf.uci.edu%usc.uucp@apple.com (Dana Roode) Organization: University of California, Irvine Subject: DN1000 vs DN3500 file size Message-Id: <2535@orion.cf.uci.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have a DN10000 running SR10.0 and a DN3500 running SR10.1. Why does a file occupying 992 blocks (according to ls -s) on the DN1000 take only 247 blocks (also according to ls -s) when copied to the DN3500? Dana Roode UCI From apollo-request@umix.cc.umich.edu Tue Aug 22 19:59:26 1989 Date: 21 Aug 89 16:32:29 GMT From: lambert%cheops%elecvax%usage%basser%metro%otc%murtoa.cs.mu.oz.au%munnari.oz.au%uhccux.uucp@ (Timothy Lambert) Organization: EE & CS, Uni N.S.W., Sydney, Australia Subject: Re: gpr_$text and Raster ops Message-Id: <1263@cheops.eecs.unsw.oz> References: <8908181723.AA14796@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >From article <8908181723.AA14796@umix.cc.umich.edu>, by FERGUSON@TMASL.EXXON.COM: > Why is it that gpr_$text ignores the Raster OP? How does one rubberband > text without having to BLT to memory and back? > I think I might've noticed once that gpr_$rectangle ignores ROP's also. > Any insights into why some primitives ignore raster ops? Any reason > why they should? You need to use gpr_$raster_op_prim_set. For some strange reason the default is that raster ops apply to lines and blts and not to fills (such as gpr_$rectangle and gpr_$circle_filled). This doesn't help you with text though. Tim From apollo-request@umix.cc.umich.edu Tue Aug 22 20:01:27 1989 Date: 22 Aug 89 04:00:00 GMT From: conliffe%caen.engin.umich.edu%mailrus.uucp@rutgers.edu (Darryl C. Conliffe) Organization: U of M Engineering, Ann Arbor, Mich. Subject: Re: Controlling case of returned name from name_$get_path Message-Id: <45301f87.14df5@ulsoy.engin.umich.edu> References: <45124af7.14df5@ulsoy.engin.umich.edu>, <452e55a9.1d6d5@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <452e55a9.1d6d5@apollo.HP.COM>, mishkin@apollo.HP.COM (Nathaniel Mishkin) writes: > In article <45124af7.14df5@ulsoy.engin.umich.edu> conliffe@caen.engin.umich.edu (Darryl C. Conliffe) writes: > >While using name_$get_path, I find the returned pathname > >is in all upper case letters. Does anyone know (1) why, > >and/or (2) how to get the pathname as it really exists? > > Contrary to a previous, almost correct followup to this posting, the > correct call to use is "name_$get_path_lc", not "name_$get_path_cc". > "name_$get_path_cc" (actually all the "_cc" calls) exist only for > historical reasons -- they got put out before we realized that we really > wanted all the name-returning calls to take an input parameter that > specifies the actual length of the caller's output buffer. > Nat, the _cc calls allow me to use them in code to run on SR 9.7 and SR 10. The _lc calls are defined only at SR 10. They don't help me yet! ;=) > -- Nat Mishkin From apollo-request@umix.cc.umich.edu Wed Aug 23 02:28:55 1989 Date: 23 Aug 89 02:07:41 GMT From: watcher@athena.mit.edu (chris ross) Organization: Massachusetts Institute of Technology Subject: What versions of netnews exist for Apollos? Message-Id: <13735@bloom-beacon.MIT.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Having cleared away the last of the bureaucratic red tape, I'm finally able to install the Usenet software on the Apollo ring at my work- place. I'd like to learn of other people's experiences with Apollo news sites, and will post a summary of replies. Specifically, I'm looking for answers to the following questions: Where did you acquire the basic news software? Did you start with vanilla Unix B news and customize it, or use someone else's? What Apollo-specific issues does your version address? Likewise for rn and friends -- what special hacks are required? Are you running news in a mixed SR9-SR10 network? If so, what do you feel are the key issues? Do you have separate source versions for SR9 and SR10? Howbout C news -- anyone have a *stable* Apollo port? Is this beginning to sound like an exam yet? :-) As an aside: I know this has been discussed before, but... how many find the Apollo-supplied sendmail adequate? If you have a custom version, what have you changed? Replies to any of the above questions (or on related issues), at any level of detail, are greatly appreciated. I'll try to put out a summary in two or three weeks, with a followup if necessary. FYI: we have about 220 nodes in three internets. Most run SR9.7; a handful are at 9.6 or 10.1. About 30% should be at 10.1 by the time we enter Usenet. Our link with the outside world is via uucp to uunet. thanx for any info you can provide. _____________________________________ chris ross <0> watcher@athena.mit.edu From apollo-request@umix.cc.umich.edu Wed Aug 23 02:38:35 1989 Date: 21 Aug 89 09:53:13 GMT From: ted%idunno%blender%xenlink%calgary%alberta%ubc-cs.uucp@beaver.cs.washington.edu (Ted Park) Organization: Wherever Subject: Orientation of Apollo on floor. Message-Id: <10@idunno.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu At the company where I work we have around 16 Mentor nodes (essentially DN3000 nodes) as well as around 20 nodes that we purchased from Apollo. Some of these nodes are sitting on the floor on edge - the nodes with Mentor stickers on the front sit with the tape drive towards the floor, so that the vents on the side don't get blocked, while the Apollo nodes sit so that the small light plate is upright, and the tape drive or floppy drive is in a position that media can easily be inserted. The CE from Mentor insists that vents up is the "correct" way, although you can flip it over if you get the optional stand. The Apollo people claim that the media end should go up. Although it makes most sense to set the node down flat on the desk where people can't kick it over (yeah, I guess that the drive wouldn't get jarred as badly if it was nearer to the floor if the node got knocked over) I'm curious about what other sites do. Yes, I know it's trivial and not particularly relevant, but inquiring minds still wanna know. . . If you have nodes sitting on the floor, which end do you have up?? From apollo-request@umix.cc.umich.edu Wed Aug 23 05:25:07 1989 Date: 22 Aug 89 21:28:29 GMT From: achille%cernvax%mcvax.uucp@uunet.uu.net (achille petrilli) Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Subject: Re: How can I get the Ethernet No. of an Apollo Message-Id: <1057@cernvax.UUCP> References: <507@cadlab.cadlab.de>, <349@simon.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <349@simon.UUCP> root@simon.UUCP (Local Deity) writes: >In article <507@cadlab.cadlab.de>, schmidt@cadlab.uucp (Michael Schmidt) writes: >> We have 3com Ethernet boards in one of our Apollos. Can any kind >> soul tell me, how I can get the Ethernet No. of one of these boards? >> -- > >On all of the 3com boards I have seen in the U.S. the Ethernet address is >located on the board in two places. > >On the back of the board, there is a label in English that specifies the >"NETWORK ADDRESS". This number has two parts; an assigned prefix that >identifies the interface as being manufactured by 3com, and a unique part >that identifies the specific board. > >This second part of the address is also located on the small prom chip that >encodes the address. On a 3c505 card the first part of the address is 02.60.8C >and the prom is at U17. A 3c503 card will have a similar set of lables. > >If the system is up and running you can find out the Ethernet address by using >the arp command available under UNIX. I seem to remember (it was some 2 years ago when I looked at it), that Apollo's PC/AT Eth boards are NOT the ones you can buy in a shop, due to a different ROM Apollo ships with them. Also, apparently Apollo overwrites the standard (3Com) eth address with Apollo's own address, that is 8:0:1e:??:??:??, where the last ??:??:?? stands for the hexadecimal nodeid of the machine. So the same eth board will have different h/w addresses depending on which node it is plugged in. I was checking that when first installed domain on eth and we wanted to know how much traffic was generated in, otherwise idle, conditions. Obviously it took a couple of hours to realize that the board address was overwritten :-) Achille Petrilli Cray and PWS operation From apollo-request@umix.cc.umich.edu Wed Aug 23 11:22:03 1989 Date: Wed, 23 Aug 89 10:03:47 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8908231403.AA09255@richter.mit.edu> To: apollo@umix.cc.umich.edu, ted%idunno%blender%xenlink%calgary%alberta%ubc-cs.uucp@beaver.cs.washington.edu Subject: Re: Orientation of Apollo on floor. Your Mentor person is correct. The DN3000 is designed to stand on its end with the tape/floppy at the top IF THE NODE IS MOUNTED ON THE FLOOR STAND. If the node is not mounted on the stand, you are blocking the air intake vents on the left side of the system unit. If the node is mounted on the stand, it's very hard to kick it over; but mostly you want to use a floor stand to avoid blocking the vents, overheating the unit, and sucking dirt into the system. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Wed Aug 23 11:23:25 1989 Date: Wed, 23 Aug 89 09:55:40 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8908231355.AA09223@richter.mit.edu> To: roode%hydra.cf.uci.edu%orion.cf.uci.edu%usc.uucp@apple.com Subject: Re: DN1000 vs DN3500 file size Cc: apollo@umix.cc.umich.edu Hard to say why, but ... what does ls -l say the sizes are? If the sizes reported by ls -l match, and the number of blocks used reported by ls -s is less than you would expect given the size, then I would guess that the file is probably being stored as a "sparse" file. I don't have a lot of info on these files offhand, but when we write a data file that has a lot of zeros in it the file system seems to be able to compact the file quite a bit. Try doing a diff on the two files. If they come out the same, my guess would be that the file system compacted the file when it copied it. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Wed Aug 23 12:28:04 1989 Date: Wed, 23 Aug 89 09:55:40 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8908231355.AA09223@richter.mit.edu> To: roode%hydra.cf.uci.edu%orion.cf.uci.edu%usc.uucp@apple.com Subject: Re: DN1000 vs DN3500 file size Cc: apollo@umix.cc.umich.edu Hard to say why, but ... what does ls -l say the sizes are? If the sizes reported by ls -l match, and the number of blocks used reported by ls -s is less than you would expect given the size, then I would guess that the file is probably being stored as a "sparse" file. I don't have a lot of info on these files offhand, but when we write a data file that has a lot of zeros in it the file system seems to be able to compact the file quite a bit. Try doing a diff on the two files. If they come out the same, my guess would be that the file system compacted the file when it copied it. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Wed Aug 23 12:35:20 1989 Message-Id: <8908231428.AA05457@umix.cc.umich.edu> Date: 23 Aug 89 09:11:00 CST From: "DAVE ERSTAD" Subject: Re: Controlling case of returned names from name_$get_path To: "apollo" Larry Allen correctly pointed out that compatibility libraries were shipped with SR10. However, that only helps if your software is only to be run at a site over which you have complete control. In my situation, many of the sites using my software haven't even received SR10 yet (it's being reshipped by Mentor Graphics), and of those that have, few have loaded it, fewer yet know about the compatibility libraries, and fewer still will load them. Given a choice between using the _cc calls and trying to get each and every customer to load SR10 compabilitbility packages (meanwhile blaming me for all SR10 confusion and woes, since I'd be driving their loads), teh coi the choice for me is obvious. After the world is SR10 (probably early-to-mid 90) I can switch to the _lc calls at my leisure. BTW, on a related note, kudos to Apollo for providing calling stubs for routines affected by lengthening the identifier limit from 32 characters to whatever. This is sincerely appreciated. Mentor didnsincee 't do this, and its d*mned frustrating. From apollo-request@umix.cc.umich.edu Wed Aug 23 17:38:25 1989 Date: 23 Aug 89 18:25:48 GMT From: ins_bxl%jhunix%aplcen%ginosko.uucp@uunet.uu.net (Xuyong Liu) Organization: The Johns Hopkins University - HCF Subject: Re: Apollo--4.2 BSD DOMAIN/IX Message-Id: <2351@jhunix.HCF.JHU.EDU> References: <8908212129.AA20669@spencer.cs.uoregon.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8908212129.AA20669@spencer.cs.uoregon.edu> chung@CS.UOREGON.EDU writes: >... I cannot rlogin the Apollo workstation. The message >(double underlined) I got back is > >% rlogin apollo >rlogind: All network ports in use. >================================== > >When I tried telnet, it seemed working but I got another painful >message as soon as logged on: > >Welcome to BSD4.2 DOMAIN/IX! >B# ls >acl_protos patches >Connection closed by foreign host. >================================== You have reached the right place. Check under directory /dev. How many "ttyp[0-f]" files do you have? Who are the owners of them? When you rlogin to an Apollo workstation, you take up the first available "ttyp[0-f]" file, and you are assigned to be the owner of that file. After you logout, the owner is changed back to root again. If all of these "ttyp[0-f]" are being used, you can not rlogin or telnet to the system. The solution would be to create more "ttyp[0-f]" files and corresponding "ptyp[0-f]" files with the command "crpty". As for the problem with telnet, I don't know the answer. We have an Apollo DN4000 running BSD4.3 under DOMAIN_OS 10.1. When I use telnet to access the workstation, the computer won't even allow me to login as root directly. But when you telnet, you still need an available "ttyp[0-f]" file to login. ------ Xuyong Liu liu@alpha.ece.jhu.edu ins_bxl@jhunix.uucp From apollo-request@umix.cc.umich.edu Wed Aug 23 17:46:00 1989 Date: 23 Aug 89 20:25:40 GMT From: zeleznik%cs.utah.edu%wasatch%mailrus.uucp@ames.arc.nasa.gov (Mike Zeleznik) Organization: University of Utah CS Dept Subject: WBAK/OmniBack mod/create times Message-Id: <3188@wasatch.utah.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Is there a good reason why wbak uses the mod time of a file instead of its create time for incrementals? The problem is if you "cp -p" in from another machine, or tar stuff in, the mod times will stay as the original (which is usually what one wants, along with keeping the modes). But now, in general, these "new" files won't get backed up til the next full save (unless the mod times happened to be in the right window). I don't think this would happen with ctime. This seems kind of a big hole for people who move things around. I understand OmniBack uses mod times also (correct me if I am wrong). Is there a reason for not using ctime? Thanks. 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 Aug 23 17:50:16 1989 Date: 22 Aug 89 22:35:21 GMT From: michal%kuhub.cc.ukans.edu%wupost%wuarchive%brutus.cs.uiuc.edu.uucp@tut.cis.ohio-state.edu (Merlin The Magician) Organization: University of Kansas Academic Computing Services Subject: stat(&buf) vs file ownership Message-Id: <9441@kuhub.cc.ukans.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu OK, I am calling the stat C function under bsd4.2 and SR9 for a file that is ls -ld foo d---rwx--- 1 1024 Aug 22 16:46 foo The ACL are as follows: foo.group.org.% pgndcalrse %.sys_admin.%.% pgndcalrse I am with uid that is sys_admin. Although the file 'foo' is the home dir of user 'foo', calling stat (&buf) I get the correct size (1024) mod/cre/acc date/time, but the uid and gid are garbage. At best the gid is that if sys_admin. Is this fixed in SR10 and bsd4.3 ? How can I avoid it now ? --Merlin +------------------------------+----------------------------------------------+ | Michal Chmielewski \ The inherent vice of capitalism is the | | Academic Computing Services \ unequal sharing of blessings; the | | University of Kansas \ inherent virtue of socialism is the | | Lawrence, KS 66045 \ equal sharing of miseries. | | Internet: michal@kuhub.cc.ukans.edu - Winston Churchill | | BitNet : michal@ukanvax.bitnet \ | +-------------------------------------+---------------------------------------+ From apollo-request@umix.cc.umich.edu Wed Aug 23 17:51:10 1989 Date: 23 Aug 89 20:12:56 GMT From: zeleznik%cs.utah.edu%wasatch%mailrus.uucp@tut.cis.ohio-state.edu (Mike Zeleznik) Organization: University of Utah CS Dept Subject: Re: DN1000 vs DN3500 file size Message-Id: <3187@wasatch.utah.edu> References: <2535@orion.cf.uci.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <2535@orion.cf.uci.edu> roode@hydra.cf.uci.edu (Dana Roode) writes: >We have a DN10000 running SR10.0 and a DN3500 running SR10.1. Why does a >file occupying 992 blocks (according to ls -s) on the DN1000 take only >247 blocks (also according to ls -s) when copied to the DN3500? > > Dana Roode > UCI Our 10K bsd4.3 du returns 4X the space that either /com/lst or /com/ld -a (and adding them up) do. I think ls -s returns the same as du (4X). I was told this was a problem in 10.0, but was fixed in 10.1, but we have 10.1 and still see it. Our 10.1 is dated May 8, 1989 (bldt). The version of du (from ts) which works CORRECTLY (our local office has it) seems to be Feb 6 1989, 14:00:33. The version WE have is something like 10/5/88. 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 Aug 23 20:02:50 1989 Date: 22 Aug 89 21:38:00 GMT From: gsg0384%uxa.cso.uiuc.edu%ux1.cso.uiuc.edu.uucp@uxc.cso.uiuc.edu Subject: vt100 emulation on SR10.1? Message-Id: <133000004@uxa.cso.uiuc.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi, Is there any decent vt100 or xterm emulation software beside the vt100 that comes with SR10.1? The latter is really a lemon. Is there any patch program available for vt100? I will appreciate any information. Hugh song@gate.spg.uiuc.edu From apollo-request@umix.cc.umich.edu Wed Aug 23 21:31:21 1989 Date: 23 Aug 89 20:34:19 GMT From: sridhar%usceast%ncrcae%hubcap.uucp@gatech.edu (M. A. Sridhar) Organization: University of South Carolina, Columbia Subject: Filename completion by csh ? Message-Id: <2895@usceast.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The manual for SR10.1 says that the C shell completes filenames (a la BSD4.3) if you set the filec variable. I tried it, but it doesn't work under DM. Could anyone tell me why? If it matters, I'm running Domain with the "medium" version of BSD4.3 on a DN3000. -- 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 Wed Aug 23 23:29:42 1989 Date: 24 Aug 89 01:21:12 GMT From: shull%scrolls.wharton.upenn.edu%netnews.upenn.edu.uucp@rutgers.edu (Christopher E. Shull) Organization: Decision Sciences, Wharton School, U of Pennsylvania Subject: Re: Orientation of Apollo on floor. Message-Id: <13870@netnews.upenn.edu> References: <10@idunno.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <10@idunno.UUCP> ted@idunno.UUCP (Ted Park) asks how folks orient their stand-on-end DN3000's. We bought a bunch of floor stands, figuring that Apollo probably designed them to hold the systems right side up. If you don't want to pay for the stands, you can still put the vents at the correct, floorward side by sticking a couple of bricks or a thick phone book under the system unit, carefully avoiding the vents. We only did this when we could also lean the top or bottom of the system unit flat against a wall or pedestal desk. We eventually bought the floor stands because I was afraid that some graduate student would see the phone book only part way under the system and "fix" it. -Chris From apollo-request@umix.cc.umich.edu Wed Aug 23 23:30:54 1989 Date: Wed 23 Aug 89 19:07:02-PST From: Steve Albrecht Subject: Re: SCSI adaptors, floppy drives To: reb%quintro%tiamat.uucp@uunet.uu.net Cc: apollo@umix.cc.umich.edu Message-Id: <619927622.870000.ALBRECHT@CALIPH> In-Reply-To: <1989Aug14.142109.1781@quintro.uucp> Mail-System-Version: Roger Benz (reb%quintro%tiamut.uusp@uunet.uu.net) stated in a recent message that mounting, wbak/rbak, or tar to high density floppy is an acceptable backup solution. While I have not tried this yet under SR10 (or SR9.7, either), I did extensive tests under SR9.6 and found that sizable items stored on floppies by any of these methods were almost always unrestorable without data losses. Until this situation is amended, DON'T COUNT ON FLOPPY BACKUP! Besides, cart tape is (somewhat) faster. (:::::::::::::::::::::::::::::::::::::::::::::) ) Steve Albrecht IntelliCorp,Inc. ( ( Knowledge Systems Product Development ) ) "Opinions expressed in this message are my ( ( own, if anyone's, and not my employer's." ) ) CSNET albrecht@intellicorp.com ( ( UUCP ...!sun!intellicorp.com!albrecht ) ) or ...!sun!icmv!albrecht%caliph ( (:::::::::::::::::::::::::::::::::::::::::::::) ------- From apollo-request@umix.cc.umich.edu Wed Aug 23 23:35:06 1989 Date: 24 Aug 89 02:13:14 GMT From: zeleznik%cs.utah.edu%wasatch%mailrus.uucp@tut.cis.ohio-state.edu (Mike Zeleznik) Organization: University of Utah CS Dept Subject: Re: WBAK/OmniBack mod/create times Message-Id: <3192@wasatch.utah.edu> References: <3188@wasatch.utah.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <3188@wasatch.utah.edu> zeleznik%cs.utah.edu@wasatch.utah.edu (Mike Zeleznik) writes: >Is there a good reason why wbak uses the mod time of a file instead of its >create time for incrementals? > Please note: I realize mod time is the logical choice by its name. Create time just seemed to catch more common changes in the files than mod time. >From what I have seen, both create and mod time are reset on append and on edit, but create time will also catch the previously mentioned common situations that mod time misses. However, as was pointed out, there are some things create time will miss (e.g., in place mods). Does mod time really end up catching more of the more common changes? Would you really need to use both to be sure of catching all changes? Thanks, 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 Thu Aug 24 07:20:31 1989 Date: 24 Aug 89 07:10:20 GMT From: chung%CS.UOREGON.EDU.uucp@ucbvax.Berkeley.EDU Subject: Cont: Apollo--4.2 BSD DOMAIN/IX Message-Id: <8908240710.AA07427@spencer.cs.uoregon.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi, E-buddies: In article <8908212129.AA20669@spencer.cs.uoregon.edu> chung@CS.UOREGON.EDU writes: >... >got a problem. I cannot rlogin the Apollo workstation. The message >(double underlined) I got back is > >% rlogin apollo >rlogind: All network ports in use. >================================== > > >When I tried telnet, it seemed working but I got another painful >message as soon as logged on: > >% telnet apollo >Trying... >Connected to apollo-gateway. >Escape character is '^]'. > > >4.2 BSD DOMAIN/IX (uo_apollo_1) > >login: root >Password: > >Welcome to BSD4.2 DOMAIN/IX! >B# ls >acl_protos patches >Connection closed by foreign host. >================================== Thank you very much for the reply. I am right now "floating" in these replies. I won't be drowned since I know how to "e-swim." b-) Tell you what: I have not solved my problem(s) yet but I am glad that you e-buddies gave me a lot of e-help. The way to solve the "network ports in use" is to run /etc/crpty in the object host(called Apollo1) with parameter 16. Most of you e-guys do not know what was wrong with the latter one, not me either. I would like to see the answer of it even though it is a little bit fishy. But I believe (as one of the replies said) if the first problem is solved, the second will disappear. I deleted all the files ttyp0 thru ttypf in /dev, and then recreated them by running the /etc/crpty. After that, I restarted the Apollo1 file server. Now, another problem comes up, see what I got when I tried to rlogin in several times. System messages are double underlined. CASE I: spencer: /home/skinner/chung 34> rlogin apollo1 Password:Connection closed. ================= CASE II: spencer: /home/skinner/chung 35> !! rlogin apollo1 Password:read: Connection reset by peer ============================== Connection closed. ================= spencer: /home/skinner/chung 36> CASE III: spencer: /home/skinner/chung 37> !! rlogin apollo1 Login incorrect login: root Password:read: Connection reset by peer ============================== Connection closed. ================= spencer: /home/skinner/chung 38> CASE IV: spencer: /home/skinner/chung 38> !! rlogin apollo1 Password: Login incorrect login: root Password: Welcome to BSD4.2 DOMAIN/IX! B# wd wd: not found B# B# B# B# ls read: Connection reset by peer ============================== Connection closed. ================= Interesting though that Apollo1 will never recognize the first password entry. Also, the response is extremely slow (in minutes). I really don't know what to do with these... 8-( Could you guys give me some help again? By the way, I am sorry for the incomplete information that I posted out last time. In fact, I try to rlogin to Apollo1 from the Tektronix ------------------------------------------------------ workstations (4317, 4325, etc)and another 4.3 BSD Unix system in our -------------------------------------------------------------------- CIS department. There is no problem at all to rlogin to other Tek ------------------------------------------------------------------ workstations and the 4.3 Unix system. ------------------------------------ An entry level system staff and entry level UNIX system programmer that I am, I expect to see your suggestions and hints. Thanks again for your friendly help. Wing Wingkuen Chung | chung@uoregon.edu P. O. Box 3120 | University of Oregon Eugene, OR 97403 | Eugene, OR 97403 (503)485-0844 | (503)686-4151 ============================================================================== Hmm!???? Ah??? Well, let me see! Gee! What? Come on. Y-{ OK. See my e-buddies. ???????? -------> DONE ------> Time to sleep. (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*) From apollo-request@umix.cc.umich.edu Thu Aug 24 07:24:29 1989 Date: 24 Aug 89 04:32:36 GMT From: abair%oakhill%cs.utexas.edu%milano%bigtex%texbell%texsun%sun-barr.uucp@decwrl.dec.com (Alan Bair) Organization: SPS CAD, Motorola Inc., Austin, Texas. Subject: Re: Apollo--4.2 BSD DOMAIN/IX Message-Id: References: <8908212129.AA20669@spencer.cs.uoregon.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <2351@jhunix.HCF.JHU.EDU> ins_bxl@jhunix.HCF.JHU.EDU (Xuyong Liu) writes: DN4000 running BSD4.3 under DOMAIN_OS 10.1. When I use telnet to access the workstation, the computer won't even allow me to login as root directly. But ^^^^^ ^^^^^ ^^^^^^^^^^^^^ Root login is controlled by the /etc/ttys file. By default, the console is the only login port allowed for root. For remote login, you need to add entries for ptys with the "secure" field on. Look at this file and read manual descriptions for more details on how to set this up. Alan Bair SPS CAD Austin, Texas Motorola, Inc. UUCP cs.utexas.edu!oakhill!turbinia!abair From apollo-request@umix.cc.umich.edu Thu Aug 24 09:29:20 1989 Date: 23 Aug 89 15:42:15 GMT From: dclemans%mntgfx%sequent%tektronix%zephyr.ens.tek.com.uucp@uunet.uu.net (Dave Clemans @ APD x1292) Organization: engr Subject: Re: What versions of netnews exist for Apollos? Message-Id: <1989Aug23.154215.165@mentor.com> References: <13735@bloom-beacon.MIT.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The big problem you see with the news software on Apollos (provided you set it up so that all the Apollo nodes look like one big "pseudo" machine, which is what most people I've heard of have done) is that the Usenet software expects standard Unix file locking semantics, that is no locking at all. Apollo's enforce exclusive file write access across a network. We run Cnews as the Usenet "transport" service. I didn't have any real problems in bringing the recent release of Cnews up; it's been quite stable. Note that if you compile Cnews as a Sys5 program you WANT to use one of the public domain dbm library emulators; what the Cnews build script gives you by default to replace the standard dbm libraries is an extremely slow sequential search. I have all the "standard" news reading programs up; readnews, vnews, rn and vn. To work around the file locking problems they actually read an "active.copy" file instead of "active". "active.copy" is updated from "active" every 15 minutes by a cron job that runs on our mail/news gateway node. rn was also modified to not hold the active file continually open (which would prevent active.copy from being updated from active...) I tried once to compile nn (under sys5) but it had problems with hanging after reading one character. I haven't had time to look at it to see why, or to try to compile it instead as a bsd program. Dave Clemans Mentor Graphics From apollo-request@umix.cc.umich.edu Thu Aug 24 15:23:48 1989 Date: 24 Aug 89 18:47:44 GMT From: dennis%peanuts.nosc.mil.uucp@nosc.mil (Dennis Cottel) Subject: Re: What versions of netnews exist for Apollos? Message-Id: <1431@nosc.NOSC.MIL> References: <13735@bloom-beacon.MIT.EDU>, <1989Aug23.154215.165@mentor.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu dclemans@mentor.com (Dave Clemans @ APD x1292) writes: > I tried once to compile nn (under sys5) but it had problems with hanging > after reading one character. I haven't had time to look at it to see why, > or to try to compile it instead as a bsd program. Under SR9.7, NN compiles and runs fine as a BSD4.2 program (not counting a couple of makefile problems). We are only using NNTP to a non-Apollo news server and not the full news setup. 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 Thu Aug 24 15:32:23 1989 Date: 24 Aug 89 18:45:34 GMT From: eao%gem.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu (Ed Overman) Organization: Dept of Mathematics, The Ohio State University Subject: Tek 4014 on an Apollo? Message-Id: <165@shape.mps.ohio-state.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I'm sorry to be asking questions that are probably often asked but I have not read this newsgroup before (this is canonical excuse #1). The reason I do not read it is because I have a Sun computer (please, no flames). However I am presently in Denmark working at the Technical University of Denmark just outside of Copenhagen and I have an Apollo series 3000 to work with. (I am VERY glad that I can work on it because the alternatives are horrible - namely Amdahl computers, including a supercomputer, running VM and TSO and MVS and possibly some other ungodly operating systems.) Back to the matter at hand. Is there a (decent) Tektronix emulator package out there somewhere? I have had a look at Apollo's and find it incredible that anyone would be willing to pay 10000 kroner ($1500) for something that will only operate over serial ports. What is the Apollo ring for? Well, anyway what I need is a basic Textronix emulator (like the one that comes FREE with all Sun computers) so that I can run some of my (interactive) graphics programs on the Apollo. Also I need to be able to crp to the one machine on this ring which is connected to the Danish network so that I can telnet to our Cray at Ohio State and run some of my graphics packages interactively. Please e-mail me any ideas at eao@shape.mps.ohio-state.edu (128.146.7.200) . Also, can you tell me where some anonymous ftp sites are for public domain Apollo software. The system administrator here, Jarl Jenson, would be grateful for any responses. He is a faculty member and has taken it upon himself to set up this ring and keep it working. (Presently there are > 50 computers on it.) Thanks, Ed Overman From apollo-request@umix.cc.umich.edu Thu Aug 24 17:29:48 1989 Message-Id: <8908242031.AA14808@umix.cc.umich.edu> Date: Thu, 24 Aug 89 16:25 EDT From: FERGUSON%TMASL.EXXON.COM@CUNYVM.CUNY.EDU Subject: X11/RAI Distribution Tape To: apollo@umix.cc.umich.edu X-Vms-To: APOLLO OK, smart guys, I thought this was resolved some time ago, but I guess not. I just got Domain/X11, which only runs on 9.7, and it was sent on SR10-format RAI form! Didn't the Apollo people admit that this is kind of silly, and that it would be fixed, or did they admit that it was silly, and proceed to chuckle merrily... Scott Ferguson, forever 9.7 so it seems... Exxon Research & Engineering Route 22 East Annandale, NJ 08801 p.s. I can't make the New Orleans thing, but if anyone thinks of it, please whine irritably about the fact that sr10 has been out for so long, and so many people are at 9.7 still because of 3rd party support software lags. Thanks. From apollo-request@umix.cc.umich.edu Fri Aug 25 05:21:04 1989 Date: 25 Aug 89 07:16:38 GMT From: lnz%lucid.com%polya%shelby%agate.uucp@ucbvax.Berkeley.EDU (Leonard N. Zubkoff) Organization: Lucid, Inc. Menlo Park, CA Subject: Re: Controlling case of returned names from name_$get_path Message-Id: <2136@heavens-gate.lucid.com> References: <8908222029.AA13624@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu It is quite possible to construct programs which run in both an SR9.7 and an SR10.1 environment using the optimal calls (_cc for SR9.7 and _lc for SR10.1) for each environment by building an OBJ rather than COFF object and having the program determine at run time which environment it is running in. Domain/CommonLISP uses precisely this technique so that the same program can run in either environment. Here is an example: if DomainSR10 then Name_$Get_Path_LC('/',1,sizeof(RootName), RootName,RootNameLength,Status) else Name_$Get_Path_CC('/',1,RootName,RootNameLength,Status); As long as the string arguments are declared with UNIV, passing in a variable of type Name_$Long_Pname_T to Name_$Get_Path_CC will work fine. Leonard From apollo-request@umix.cc.umich.edu Fri Aug 25 11:31:30 1989 Message-Id: <8908251417.AA05060@umix.cc.umich.edu> Date: 25 Aug 89 08:54:00 CST From: "DAVE ERSTAD" Subject: Detecting SR10 To: "apollo" Anyone know a convenient way to test at run time whether one is at SR9.7 or SR10? I need to do this in both Pascal and C. Dave Erstad Principal Design Automation Engineer Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Fri Aug 25 13:21:48 1989 Date: 18 Aug 89 15:14:48 GMT From: michal%kuhub.cc.ukans.edu%wuarchive%brutus.cs.uiuc.edu.uucp@apple.com (Merlin The Magician) Organization: University of Kansas Academic Computing Services Subject: Re: Accounting ? Message-Id: <9044@kuhub.cc.ukans.edu> References: <8908180858.AA04835@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Let's see. In 2 or 3 weeks we are supposed to install the SR10 I believe so hold your good advice till then. If I still can't find a trace of accounting software, y'all will hear from me, ya' hea' ? -Merlin From apollo-request@umix.cc.umich.edu Fri Aug 25 15:23:07 1989 Date: 25 Aug 89 00:54:00 GMT From: weber_w%apollo.uucp@eddie.mit.edu (Walt Weber) Organization: Hewlett-Packard, Apollo Division, Chelmsford, MA Subject: Re: stat(&buf) vs file ownership Message-Id: <453ae25a.10b48@apollo.HP.COM> References: <9441@kuhub.cc.ukans.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <9441@kuhub.cc.ukans.edu> MICHAL@kuhub.cc.ukans.edu (Merlin The Magician) writes: >OK, > > I am calling the stat C function under bsd4.2 and SR9 for a file >that is > ls -ld foo > d---rwx--- 1 1024 Aug 22 16:46 foo > > The ACL are as follows: > foo.group.org.% pgndcalrse > %.sys_admin.%.% pgndcalrse > >I get the correct size (1024) mod/cre/acc date/time, but the uid and >gid are garbage. Unfortunately, the ACL shown above will not be able to be translated into valid Un*x owner/group ID's, since it is not an acl which is created by chmod(1) or open(2), for example. See the System Administration for BSD4.2 manual, starting at page 5-14 and the approx. 6 pages following for a discussion of how SR9 starts with an ACL and derives the mode bits. It will behave as you expect at sr10; avoid the behavior by using unix commands to create files, and not Aegis commands. You might also wish to review the command /etc/sup, documented in section 8 on the BSD side, section 1M on the SYS5 side. ...walt... -- Walt Weber Hewlett-Packard, Apollo Division (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 Fri Aug 25 15:32:09 1989 Date: Fri, 25 Aug 89 15:00:27 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8908251900.AA15488@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: ADUS conference / users suggestions At this year's ADUS conference each of the SIG's will poll their members for suggestions to be given during the general engineering directions session. I will be chairing the University SIG session, and I would like to be able to have some suggestions from the SIG members prior to the conference so that we can include ideas from those University SIG members who may not be able to attend the New Orleans bash. If you have any ideas to kick off our session with, please send them to me in the next week. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Fri Aug 25 17:27:29 1989 Date: Fri, 25 Aug 89 16:52:09 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8908252052.AA15921@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: Need IP number Sorry for this folks ... Donal O Coileain, My return mail to you seems to be going into the ether. Could you please send me the IP number for your host so I can send mail to you directly? -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Fri Aug 25 19:22:16 1989 Message-Id: <8908252153.AA16752@umix.cc.umich.edu> Date: 25 Aug 89 16:49:00 CST From: "DAVE ERSTAD" Subject: Re: Detecting SR10 To: "apollo" > Under SR9.7 if you created a file with > the name_$ calls with the name "FOOBAR" > and then tried to read back the name using > the name_$xxx_cc (case correct) calls you > should get "foobar", I think. Testing name > case sensitivity would be the easiest way > I can think of. If the DOWNCASE environment variable is set to FALSE at SR9, this will give an incorrect answer. However, the same person who pointed that out to me also made a related suggestion: Just try creating a file whose leaf is greater than 32 characters. The following function seems to work, for those interested: function sr10 : boolean; %include '/sys/ins/base.ins.pas'; %include '/sys/ins/name.ins.pas'; const file_name = '/tmp/foobarfoobarfoobarfoobarfoobarfoobar'; var is_sr10, is_sr9 : boolean; status : status_$t; begin name_$create_file(file_name, sizeof(file_name), status); is_sr10 := status.all = status_$ok; is_sr9 := status.all = name_$bad_leaf; if not (is_sr10 or is_sr9) then writeln('Abnormal status from SR10 detection function: ', status.modc:8, status.code:8); { cleanup } name_$delete_file(file_name, sizeof(file_name), status); sr10 := is_sr10; end; Dave Erstad Principal Design Automation Engineer Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Fri Aug 25 19:22:59 1989 Date: 25 Aug 89 21:07:48 GMT From: turner%bwana.sps.mot.com%dover%oakhill%cs.utexas.edu%csd4.csd.uwm.edu%gem.mps.ohio-state. Organization: Motorola, Inc., Semiconductor Products Sector Subject: 16 Megs of Ram on a DN3000??? Message-Id: <1753@dover.sps.mot.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Yes, I know the Apollo line, "DN3000 have the the capability of having 8 Megabytes of memory." My problem is some vendors, especially X Window types, are saying 8 Megs are required and 16 Megs are preferred. Some of us have been around long enough to remember when your machine ran out of addressing space, you cut a few traces, added a resistor and an IC, and "magic" you've increased your memory capacity. Latest example is the Macs going from 128K of RAM to 512k. Does anybody with a real smart soldering iron know how to do this on my old, but beloved DN3000. Has anybody at Apollo figured this out? The first answer is: "No the budget isn't large enough to justify upgrading 25 DN3000s to DNxxxxs including Apollo's and the third party vendors charges." Any ideas? Robert Robert Turner (602) 994-6837 ...!uunet!dover!turner or turner@dover.sps.mot.com "I don't care who does the electing as long as I get to do the nominating" -- Boss Tweed From apollo-request@umix.cc.umich.edu Sat Aug 26 00:57:25 1989 Date: 24 Aug 89 12:52:15 GMT From: jnp%newshost%mjolner%santra%tut%sunic%mcsun.uucp@uunet.uu.net (J|rgen N|rgaard) Organization: none Subject: HELP, HELP, HELP !!! (rgy_admin) Message-Id: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu During a thunderstorm lately our Apollos were interrupted. This is not so bad -- apart from that the registry-service, politely expressed, is unreliable ! '/etc/rgy_admin' is unable to start at all. 'edrgy' informs that the registry at "//my_host" read-only (or similar). BUT I NEED rgy_admin TO MAKE //myhost" MASTER !!! So what can be the problem. The manual does not provide any clues. My machine used to be a replica. But due to a repeater fall out I want it to become master on my part of the network. Partly because mail just "goes away with out notice" (actually SIG 13, but the result is the same) Can I delete certain files to make my machine believe it is alone on the net ? -- -- -- | Regards, J|rgen N|rgaard ('|' is '\o{}' in \LaTeX{}) | | e-mail: jnp@tele.nokia.fi or pedersen%tnclus.dnet@tele.nokia.fi | -- telephone: <..>-358-0-511-5671 -- From apollo-request@umix.cc.umich.edu Sat Aug 26 11:22:47 1989 Date: 26 Aug 89 12:04:48 GMT From: culmer%grad1.cis.upenn.edu%netnews.upenn.edu%eecae%tank.uucp@speedy.wisc.edu Organization: University of Pennsylvania Subject: Latest version of DOMAIN/IX? Message-Id: <13920@netnews.upenn.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu This is a simple question. Can someone please tell me the answer FOR SURE? I have a Domain 3000 with AEGIS version 9.7. I ordered DOMAIN/IX and was told I would receive version 9.7.1, the latest version. The cartridge I received was labeled version 9.5. The salesman checked and told me that that 9.5 was the latest version of DOMAIN/IX. I have subsequently ordered the Apollo version of X-windows. The salesman (a new guy) says I need version 9.7 of DOMAIN/IX. What is the latest version of DOMAIN/IX? Thanks. Charles W. Culmer culmer@grad1.cis.upenn.edu Truth, justice, and the Canadian way From apollo-request@umix.cc.umich.edu Sat Aug 26 11:22:54 1989 Date: 24 Aug 89 12:31:02 GMT From: lapalme%ouareau%iros1%mcgill-vision.uucp@BLOOM-BEACON.MIT.EDU (Guy Lapalme) Organization: Universite de Montreal Subject: Pascal on Apollo Message-Id: <1119@mannix.iros1.UUCP> References: <8904191409.AA03566@lnic1.hprc.uh.edu>, <182@santa_fe.UUCP>, <42c0652f.17dde@apollo.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have been using the Apollo Pascal Compiler for teaching undergraduates but we have been very disappointed with it: - it does not detect subrange overflow - it does not have conformant array - there are all kinds of loopholes in the type checking - it does not check overflow on input (so reading 12344567890234568 might return -34...) In summary, there are all kinds of "extensions" but the basic and clean Pascal needed for teaching undergraduate is not implemented correctly. Is somebody aware of a better Pascal compiler to use on Apollos? Thank You Guy Lapalme Dept Informatique et Recherche Operationnelle Universite de Montreal CP 6128, Succ A Montreal Quebec Canada H3C 3J7 Tel:(514)343-7220 -- Guy Lapalme Dept Informatique et Recherche Operationnelle Universite de Montreal CP 6128, Succ A Montreal Quebec Canada H3C 3J7 Tel:(514)343-7220 From apollo-request@umix.cc.umich.edu Sat Aug 26 17:19:10 1989 Date: Sat, 26 Aug 89 16:34:20 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8908262034.AA17357@richter.mit.edu> To: culmer%grad1.cis.upenn.edu%netnews.upenn.edu%eecae%tank.uucp@speedy.wisc.edu Subject: Re: Latest version of DOMAIN/IX? Cc: apollo@umix.cc.umich.edu We are running both SR9.7, SR9.7.1, and SR9.7.5 (all of which are basically the same rev. of AEGIS with patches added to handle the latest hardware options) on our network. The last version of DOMAIN/IX which we received was shipped with SR9.5. The installation instructions for the original SR9.7 release said to use the SR9.5 version of DOMAIN/IX. We have received no futher releases of DOMAIN/IX since then, and we are on a full maintenance contract (so if there had been any releases after SR9.5, we would of received them). -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Sun Aug 27 01:19:56 1989 Date: 27 Aug 89 03:51:00 GMT From: stealth%caen.engin.umich.edu%mailrus.uucp@ames.arc.nasa.gov (Mike Peltier) Organization: University of Michigan Engineering: Ann Arbor, Michigan Subject: Re: OS Updates and Solution Suppliers Message-Id: <45458f3d.b617@bear.engin.umich.edu> References: <8908181731.AA15625@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8908181731.AA15625@umix.cc.umich.edu> FERGUSON@TMASL.EXXON.COM writes: >Whenever Apollo makes these radical OS changes, there's a HUGE (capital H) >time lag before the third party software/peripheral vendors bother to >come out with a new revision of their support software. For instance: > [examples deleted] Perhaps the developers need to be briefed ahead of time about the impending changes to the operating system, and have the opportunity to use and explore the new verion before it is released to the public, instead of at the same time. Software revision takes time, I don't think it's just a matter of the developers sitting on their duffs all day. -- - - - - - - - - - Michael V. Peltier | Computer Aided Engineering Network 1420 King George Blvd. | University of Michigan, Ann Arbor Ann Arbor, MI 48104-6924 | stealth@caen.engin.umich.edu From apollo-request@umix.cc.umich.edu Sun Aug 27 01:21:29 1989 Date: 27 Aug 89 04:03:00 GMT From: stealth%caen.engin.umich.edu%mailrus.uucp@ames.arc.nasa.gov (Mike Peltier) Organization: University of Michigan Engineering: Ann Arbor, Michigan Subject: Re: DN1000 vs DN3500 file size Message-Id: <45459a17.b617@bear.engin.umich.edu> References: <2535@orion.cf.uci.edu>, <3187@wasatch.utah.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <2535@orion.cf.uci.edu> roode@hydra.cf.uci.edu (Dana Roode) writes: >We have a DN10000 running SR10.0 and a DN3500 running SR10.1. Why does a >file occupying 992 blocks (according to ls -s) on the DN1000 take only >247 blocks (also according to ls -s) when copied to the DN3500? > > Dana Roode > UCI The manual page for 'ls' indicates that the -s option prints the size of the file in kilobytes. A file containing "This is a test." showed up as " 16 -rw-r--r--" on our DN10k, but as " 1 -rw-r--r--" on a DN3.5k. I think I recall this having something to do with bigger block sizes on the 10k -- 16kbyte blocks rather than 1kbyte blocks? That would be the natural conclusion given the above information... - - - - - - - - - Michael V. Peltier | Computer Aided Engineering Network 1420 King George Blvd. | University of Michigan, Ann Arbor Ann Arbor, MI 48104-6924 | stealth@caen.engin.umich.edu -- - - - - - - - - - Michael V. Peltier | Computer Aided Engineering Network 1420 King George Blvd. | University of Michigan, Ann Arbor Ann Arbor, MI 48104-6924 | stealth@caen.engin.umich.edu From apollo-request@umix.cc.umich.edu Sun Aug 27 11:22:42 1989 Date: 26 Aug 89 16:31:54 GMT From: davek%hp-lsd%hpldola%hpfcso.uucp@hplabs.hp.com (Dave Kumpf) Organization: HP Logic Systems Division - ColoSpgs, CO Subject: Need help with DN300 station Message-Id: <11360001@hp-lsd.COS.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I recently acquired a DN-330 (says DN300-3MB on back, 68020 CPU + 68881 inside) at a surplus sale. With it, I got a SMSD-70M disk (no floppy drive) and most of the Aegis 9.2.3 distribution and manuals. I'd like to get this system running, so I have a few questions: 1) I'm short a couple disks on the 9.2.3 Aegis distribution. Anyone have spares? 2) Does anyone have hardware and service manuals for the above stuff? I got mostly user's guides, software installation and some programming reference stuff. 3) The disk I got contains the hard drive only, not the floppy. I know I can buy 8" drives from surplus houses; the question is, which brand/model? Is the hardware to drive the floppy built in to the unit? (I'd rather not be a floppy controller designer ...) What cable do I need? 4) Finally, when I hook my disk up, the Apollo turns on OK. (although Ring test fails -- presumably because there's no net connection -- what do I use for terminators? (50 ohm terminators?)). If I then execute: >RE > MD2x .............. >EX AEGIS (i.e. the Aegis distribution is apparently already on the disk) The Kernel message for Aegis is then printed at the top of the screen. After a long time, there is a message that the station address doesn't match the one on the boot volume; it asks if I want to proceed. I type yes; I haven't waited long enough to find out if anything else happens. Given that there is a 68020 in the box, I can't imagine that this unit takes longer to boot than a Xerox NS8000 server (40+ minutes ...). Any ideas? (if it helps, ex of some of the other files, such as CPT1, etc, SALVOL seem to work OK.) 5) What kind of mouse does this unit use? It looks like the keyboard has a 9-pin serial port for a mouse: Logitech? Mouse Systems? Microsoft? 6) Now for the wish list: Is there an X11 port for this unit? Do I want to run it in only 3 MB or will it be a hog? Does anyone have a copy of Interleaf for this unit that they would give up cheap? (WPS would be OK, TPS better) Where can I find more general information on Apollos? (I realize that this is an older machine, but somewhere there's got to be data ...) (Sorry if these questions seem lame, but I have no prior experience with Apollo, just HP9000/HP-UX and PCs. Right now, I'm lost trying to figure out what's going on with Apollo's OS. What is it really called: Aegis? Domain_OS? Is it now really UN*X (in SR10)? ????) Thanks. Dave Kumpf hplabs!hp-lsd!davek davek%hp-lsd@hplabs.hp.com Mail: HP Logic Systems Division P.O. Box 617, Colorado Springs, CO 80901-0617 (mail) 8245 N. Union Boulevard, Colorado Springs, CO 80920 (shipments) Phone: (719) 590-5739 From apollo-request@umix.cc.umich.edu Sun Aug 27 17:23:32 1989 From: stan%dbi%uunet.uucp@umix.cc.umich.edu Date: Sun, 27 Aug 89 15:43:42 -0400 Message-Id: <8908271943.AA03965@uunet.uu.net> To: apollo%umix.uucp@umix.cc.umich.edu Subject: better Pascal on Apollo Cc: stan@umix.cc.umich.edu In <1119@mannix.iros1.UUCP>, Guy Lapalme writes: Is somebody aware of a better Pascal compiler to use on Apollos? ana-systems sells a Modula-2 compiler that is being used for teaching, research, and product development on DN3000/DN4000 class machines. Stan Osborne, stan@ana.com or {...!}uunet!ana.com!stan From apollo-request@umix.cc.umich.edu Mon Aug 28 11:21:31 1989 Date: Mon, 28 Aug 89 10:46:50 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8908281446.AA20476@richter.mit.edu> To: davek%hp-lsd%hpldola%hpfcso.uucp@hplabs.hp.com Subject: Re: Need help with DN300 station Cc: apollo@umix.cc.umich.edu A few things ... 1) just get a regualr rignet cable and loop it back to the node for the network problem. Terminators won't do. It's a ringnet, not an ethernet. It wants to see a token being passed on the net. 2) The floppy controller is built into the hard disk controller. You should have a pair (2) of flat ribbon cables which connect both the hard disk and the floppy (which is mounted in the top of the hard disk cabinet) to the CPU. 3) Your hard disk was initialized on a machine other than the one you now have it connected to. The apollo file system has the CPU ID number attached to each file to help with the distributed file system (it insures that each file has a uniquie ID number even if two or more machines on the network have files of that same name/creation date/type/etc). Use the command "ex chuvol" to change the CPU ID numbers on the disk before you try to boot it. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Tue Aug 29 01:16:09 1989 Message-Id: <8908290146.AA03033@mitre.arpa> Organization: The MITRE Corp., Washington, D.C. To: apollo@umix.cc.umich.edu, art@mwunix.mitre.org Subject: Need information on OMNIBACK Date: Mon, 28 Aug 89 21:46:46 EDT From: Art McClinton Is anyone using the OMNIBACK package from Apollo? * *---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 DECUS DCS: MCCLINTON * From apollo-request@umix.cc.umich.edu Tue Aug 29 09:21:22 1989 Date: 28 Aug 89 22:10:20 GMT From: dataxpress%cup.portal.com%portal.uucp@uunet.uu.net (John Philip Eurich) Organization: The Portal System (TM) Subject: Re: Pascal on Apollo Message-Id: <21662@cup.portal.com> References: <8904191409.AA03566@lnic1.hprc.uh.edu>, <182@santa_fe.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In reply to Guy Lapalme's article < We have been using the Apollo Pascal Compiler for teaching undergraduates < but we have been very disappointed with it: < - it does not detect subrange overflow < - it does not have conformant array < - there are all kinds of loopholes in the type checking < - it does not check overflow on input (so reading 12344567890234568 < might return -34...) < In summary, there are all kinds of "extensions" but the basic and clean < Pascal needed for teaching undergraduate is not implemented correctly. < < Is somebody aware of a better Pascal compiler to use on Apollos? MetaWare, Inc. of Santa Cruz, CA has a Pascal compiler that runs on a number of platforms, including Apollo. They call it Professional Pascal and it is by far one of the best Pascal compilers on the market. Their phone number is (408) 429-6382. John Eurich From apollo-request@umix.cc.umich.edu Tue Aug 29 11:28:49 1989 Message-Id: <8908291258.AA03180@umix.cc.umich.edu> Date: Tue, 29 Aug 89 20:54:05 SST From: fclim Subject: Please remove me from the list. To: One ADU to another Please remove gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu from the mailing list. Thanx. fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Add your pet peeve If we think really hard, maybe we can stop this ____! No ____! No ____! No ____! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From apollo-request@umix.cc.umich.edu Tue Aug 29 13:22:36 1989 Date: 29 Aug 89 12:53:19 GMT From: Chuck_SirVAX_Staatse%cup.portal.com%portal.uucp@uunet.uu.net Organization: The Portal System (TM) Subject: Pinouts Message-Id: <21675@cup.portal.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu From: JAY 16-AUG-1989 09:07 To: CHUCK,JAY Subj: APOLLO CONNECTOR INFORMATION REQUEST I need information concerning the pinouts and signal titles on the memory bus connector for the Apollo DN3000, DN3500, DN4000, and DN4500 workstations. Any information would be greatly appreciated. Please respond by mail. From apollo-request@umix.cc.umich.edu Tue Aug 29 13:27:42 1989 Date: 26 Aug 89 12:13:00 GMT From: oj%apollo.uucp@EDDIE.MIT.EDU (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: lpd problems , X Windows Message-Id: <454248c7.208ba@apollo.HP.COM> References: <1220@syma.sussex.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1220@syma.sussex.ac.uk> andrewn@syma.UUCP (Andrew D Nimmo) writes: > > We are running SR10.1 ( and SR10.0P on a DN10000 ) - Please! Upgrade your DN10000 as soon as possible to sr10.1.p. It really is better in many ways (the size-off-by-4x problem in du not being one of them :-) > On a completely different subject - I have X Windows Version > 2, Revision 3 up and running on our network. When will > apollo (UK or US) release their official version (with > X Windows and DM support) and the MOTIF interface? We've got three version of Domain/X11 ("share mode") released from R&D. The version for SR10.1 (for Motorola 68k computers) has been available to order for a while now. Ask for Domain/X11 version 1.1. The version for SR10.1.p (for Apollo Prism computers) will be released from manufacturing very soon if it hasn't been already. Ask for Domain/X11 version 1.1.p. If you want to run with SR9.7 ask for Domain/X11 version 1.0. There's a fee for these packages (I don't know prices, but I believe it's less than the fee MIT charges for the source kit). The X Window System will be bundled with SR10.2 on both Motorola m68k and Apollo Prism computers. From apollo-request@umix.cc.umich.edu Tue Aug 29 13:38:50 1989 Date: 28 Aug 89 18:31:00 GMT From: nazgul%apollo.uucp@eddie.mit.edu (Kee Hinckley) Organization: Apollo Computer, Chelmsford, MA Subject: Re: Filename completion by csh ? Message-Id: <454da909.1b147@apollo.HP.COM> References: <2895@usceast.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <2895@usceast.UUCP> sridhar@usceast.uucp.UUCP (M. A. Sridhar) writes: >The manual for SR10.1 says that the C shell completes filenames (a la BSD4.3) >if you set the filec variable. I tried it, but it doesn't work under >DM. Could anyone tell me why? If it matters, I'm running Domain with the >"medium" version of BSD4.3 on a DN3000. Because pads are not really terminals and don't support traditional terminal escape sequences. Think of pads and read-only or read-write editors and the system makes more sense. If you run the Cshell in a vt100 emulator or an xterm file completion should work fine. Obscure note. It actually is possible to write a keydef (with side program) that does command completion. It grabs the text behind the cursor, and cp's a program with that as an argument. The program then inserts the remaining characters. Mind you I said "possible", not "desirable"! :-) -kee -- ### User Environment, Apollo Computer Inc. ### Public Access ProLine BBS ### ### {mit-eddie,yale}!apollo!nazgul ### nazgul@pro-angmar.cts.com ### ### nazgul@apollo.com ### (617) 641-3722 300/1200/2400 ### I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. From apollo-request@umix.cc.umich.edu Tue Aug 29 21:19:06 1989 Date: 29 Aug 89 15:08:22 GMT From: esker%abaa%itivax%sharkey%mailrus.uucp@tut.cis.ohio-state.edu (Lawrence Esker) Organization: Allen Bradley Subject: Re: Will Amiga survive Message-Id: <1952@abaa.UUCP> References: <43903@tiger.oxy.edu>, <1989Aug29.041045.25405@psuvax1.cs.psu.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1989Aug29.041045.25405@psuvax1.cs.psu.edu> bralick@psuvax1.cs.psu.edu (William Anthony Bralick) writes: >In article <43903@tiger.oxy.edu> dand@oxy.edu (Daniel D. Fineman) writes: >> >>Question: will the Amy survive? > >Any truth to the rumors that HP is looking to acquire the Amiga as a >low-end workstation to complement their (newly acquired) Apollo >models? Close, actually HP is looking to aquire the Amiga as a high end workstation to migrate to as they phase out the Apollo line 8-). With an Amiga2000, a 25 MHz 68030 board, the Ameristar Ethernet, full 9 meg memory, the ECS chip set, v1.4 operating system, and a good 19 inch 1280x800 monitor you can easily outperform most of the Apollo line. What missing from the picture you say? Oh well, it doesn't have an EDSI drive controlloer for those 320 Mbyte drives. Virtual memory would be nice. We need memory boards that work outside the 9Mbyte base machine limit of the Amiga (Our Apollo server uses 32 Mbyte completely.) And damn, why are there still no readily available tape drives with software support for the Amiga? BTW. I use the Apollos at work, I would prefer an Amiga. But I doubt if VTItools will ever port their ASIC development tools. The Amiga still has some growing up to do before it would be a serious competitor to the Apollo. -- ---------- Lawrence W. Esker ---------- Modern Amish: Thou shalt not need any \ * * * ******* / computer that is not IBM compatible. \ * * * * * / \ * * * * * ***** / Sr. Hardware/ASIC Design Engineer \ * * * * * * / Allen-Bradley Communications Div. \ ******* * * ******* / Work: (313)668-2500 Home: (313)973-8561 ----------------------------- Compuserve: 76337,2524 UseNet Path: __!mailrus!sharkey!itivax!abaa!esker == esker@abaa.UUCP From apollo-request@umix.cc.umich.edu Wed Aug 30 01:16:32 1989 Date: 29 Aug 89 13:10:21 GMT From: andrewn%syma%icdoc%ukc%mcsun.uucp@uunet.uu.net (Andrew D Nimmo) Organization: University of Sussex Subject: Async. socket i/o Message-Id: <1308@syma.sussex.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Is, as is implied in the 'Programming Enviroment Reference' manual, the use of asynchronous socket i/o (using fcntl, select and signal) not possible under SR10.1 (and SR10.0.p)? If this is true when will it be implemented, or does an update exist to patch this potentially serious ommision? My problem stems from an fcntl call returning the error 'No such file or directory' when applied to a known (UNIX) socket - although this is a valid error, it does not appear to be a valid fcntl error. -- 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) ...mcvax!ukc!syma!andrewn From apollo-request@umix.cc.umich.edu Wed Aug 30 01:22:05 1989 Date: Tue, 29 Aug 89 22:07:20 CDT From: Andrew M. Wescott Message-Id: <8908300307.AA10407@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu, esker%abaa%itivax%sharkey%mailrus.uucp@tut.cis.ohio-state.edu Subject: Re: Will Amiga survive Yeah, I'll bet the entire Amiga line will obsolete the dn10000 and its offspring. You seem to assume the Apollo/HP will develop nothing beyond the 68030. We all know the 68040 is just around the corner pending some legal issues. Since Apollo has developed an excellent risc architecture in PRISM, and the rest of the industry is selling desktop risc, common sense dictates that Apollo will develope a risc desktop. I mean why would HP buy Apollo if they didn't think they could learn anything from the people in Chelmsford ? Nobody has that much idle cash. I am still laughing... I guess next year the Amiga will put all the CRAY YMPs out to pasture!!!! Get serious. Andrew Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Wed Aug 30 07:21:21 1989 Date: 29 Aug 89 16:14:20 GMT From: reb%quintro%tiamat.uucp@uunet.uu.net (Roger E. Benz) Organization: none Subject: Questions about knowledge broader Message-Id: <1989Aug29.161420.2016@quintro.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We are currently looking at getting knowledge broaker and would like comments from people who are using it. I mostly interested in 1. How is the speed of the product? 2. Does it include online Apollo documentation? 3. Is it node locked? 4. Is it easy/hard to add your own information? 5. Can ASCII terminals use it? 6. Disk space usage? 7. Other? I would also welcome general comments about the prodect. Thanks -- 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 Wed Aug 30 12:32:30 1989 Message-Id: <8908301312.AA03624@umix.cc.umich.edu> Date: 30 Aug 89 07:58:00 CST From: "DAVE ERSTAD" Subject: Re: Pascal on Apollo To: "apollo" I've used Professional Pascal (from Metaware) on the Daisy platform and generally found it to be low quality. Things like compiler crashes with useful messages like "Dynamic array allocation/ reallocation failed" (The compiler's internal arrays, not one of mine). Of course, this was a Daisy port and thus these problems may well be Daisy specific - the Daisy is not a friendly platform. Dave Erstad Prinicipal Design Automation Engineer Honeywell SSEC DERSTAD@cim-vax.honeywell.com Disclaimer: Obviously, the above is my opinion only, and doe not reflect any position of Honeywell Inc. From apollo-request@umix.cc.umich.edu Wed Aug 30 12:36:34 1989 Date: 30 Aug 89 12:24:52 GMT From: sasdvp%sas%rti.uucp@mcnc.org (David V. Phillips) Organization: SAS Institute Inc, Cary NC Subject: Re: Detecting SR10 Message-Id: <1175@sas.UUCP> References: <8908251417.AA05060@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8908251417.AA05060@umix.cc.umich.edu> derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") writes: > >Anyone know a convenient way to test at run time whether one is at >SR9.7 or SR10? I need to do this in both Pascal and C. We're using a subroutine that pgm$invokes /com/sh /com/bldt, then figures out what system was listed in the output. Icky, but it works. Dave From apollo-request@umix.cc.umich.edu Thu Aug 31 13:26:20 1989 Date: 30 Aug 89 15:27:52 GMT From: eezprandolin%csvax%uqvax%bunyip%metro%otc%murtoa.cs.mu.oz.au%munnari.oz.au%uhccux.uucp@ames. Organization: Queensland University of Technology Subject: Wanted - terminal emulator Message-Id: <4934@qut.edu.au> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Excuse my ignorance but is there a P.D. Type graphics terminal emulator around for a dn3000 under aegis ? Any help or direction in finding such an emulator would be appreciated. BOB From apollo-request@umix.cc.umich.edu Fri Sep 1 09:22:14 1989 Date: 29 Aug 89 21:15:00 GMT From: nazgul%apollo%ulowell%mailrus.uucp@tut.cis.ohio-state.edu (Kee Hinckley) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: BMF -> FBM Message-Id: <45534397.1b147@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I was unable to reply (well, I replied okay, but it bounced) to the poster who offered a BMF to FBM converter. Could you please mail a copy to nazgul@apollo.com? Many thanks. -kee -- ### User Environment, Apollo Computer Inc. ### Public Access ProLine BBS ### ### {mit-eddie,yale}!apollo!nazgul ### nazgul@pro-angmar.cts.com ### ### nazgul@apollo.hp.com ### (617) 641-3722 300/1200/2400 ### I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. From apollo-request@umix.cc.umich.edu Fri Sep 1 09:23:41 1989 Date: 30 Aug 89 18:31:00 GMT From: gaz%apollo%ulowell%mailrus.uucp@tut.cis.ohio-state.edu (Gary Zaidenweber) Organization: Apollo Computer, Chelmsford, Mass. Subject: Re: Creating a window on a remote node Message-Id: <4557b873.ce45@apollo.HP.COM> References: <1989Aug17.083649.3654@gpu.utcs.utoronto.ca> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >From article <1989Aug17.083649.3654@gpu.utcs.utoronto.ca>, by sarathy@gpu.utcs.utoronto.ca (Rajiv Sarathy): > > Why can't you just do this: > > crp "/com/crpad " -on // -me > > This will place the contents of in a read-only window > on // > > > -- > _____________________________________________________________________________ > | Disclaimer: I'm just an undergrad. All views and opinions are therefore _ | > | my own. /\ /\ /-----------------------------------oO(_)| > | / \ / \ / NetNorth: sarathy@utorgpu | > | Rajiv Partha Sarathy / \/ \/ sarathy@gpu.utcs.utoronto.ca | > | --------------------/ {uunet!attcan mnetor att pyramid}!utgpu!sarathy | > |_____________________________________________________________________________| Of course you can do that if you just wish to show a file. The reason I posted the "long C program" :-) is that sometimes you wish to actually run a program in a window, evoked from another program (which may or may not be running in a window, itself.) I figured I'd supply the useful, general-case module to do that. -- 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 Sep 1 09:28:07 1989 Date: 30 Aug 89 15:17:00 GMT From: vijay%apollo%ulowell%mailrus.uucp@tut.cis.ohio-state.edu (Vijay Sundaram) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: WBAK/OmniBack mod/create times Message-Id: <45570a6d.122ae@apollo.HP.COM> References: <3188@wasatch.utah.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <3188@wasatch.utah.edu> zeleznik%cs.utah.edu@wasatch.utah.edu (Mike Zeleznik) writes: >Is there a good reason why wbak uses the mod time of a file instead of its >create time for incrementals? > >The problem is if you "cp -p" in from another machine, or tar stuff in, the >mod times will stay as the original (which is usually what one wants, along >with keeping the modes). But now, in general, these "new" files won't get >backed up til the next full save (unless the mod times happened to be >in the right window). I don't think this would happen with ctime. > >This seems kind of a big hole for people who move things around. > >I understand OmniBack uses mod times also (correct me if I am wrong). > >Is there a reason for not using ctime? Thanks. > >Mike > > Michael Zeleznik Computer Science Dept. > University of Utah > zeleznik@cs.utah.edu Salt Lake City, UT 84112 > (801) 581-5617 OmniBack uses the modified time (dtm) *as well as* the time the attributes were changed (dta). When you do a "cp -p" the modified time remains the same, the time of creation and use gets updated. The dta also gets updated. Since OmniBack looks at whichever was updated from {dta, dtm}, no undue penalty is incurred. -- Vijay-- ------------------------------------------------------------------------------------ Vijay Sundaram vijay%apollo.hp.com Apollo Division of Hewlett-Packard {decwrl!decvax, mit-eddie, attunix}!apollo!vijay ------------------------------------------------------------------------------------ From apollo-request@umix.cc.umich.edu Fri Sep 1 09:31:51 1989 Date: 30 Aug 89 15:29:00 GMT From: nazgul%apollo%ulowell%mailrus.uucp@tut.cis.ohio-state.edu (Kee Hinckley) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: How to orient your Apollo Message-Id: <4557153e.1b147@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu --- Posted for batsford_s@apollo.com (Steven Batsford) Re: Orientation of Apollo on floor. From: Steve Batsford, Apollo R&D I performed the environmental testing on the Apollo DN3000, DN4000, DN4500, and DN3500 workstations. All of these workstations are designed to be mounted horizontally on a desk or table top, or vertically on a floor stand. When mounted on a floor stand, the tape or floppy is at the top and the left side vents are three inches the floor. If a system is mounted vertically with the left side vents blocked it will overheat. The left side vents are where most of the air that cools the AT-Bus enters the unit and if these vents are blocked the AT-Bus area only gets a bare fraction of the normal airflow. If a system is mounted vertically with the left side vents up it will also overheat. This is because in this orientation the fan is lower than the AT-Bus area. The heat being generated by the option cards is trying to rise and the fan is trying to pull that warm air down to get it out of the workstation. This causes a very sharp decrease in airflow over the option cards installed in the AT-Bus and the decreased airflow causes overheating. Even with only two or three option cards installed in the option slots a system can overheat if installed incorrectly. You may not have a hard failure, or any definable problem, but overheating can cause chips on the option cards to behave strangely causing hard to diagnose and unnecessary problems. On page 24 of the manual "Unpacking and Installing Your Domain Personal Workstations and Servers", (Apollo part no. 007857-A00), there is a diagram that shows the minimum clearances allowed from each side of the workstation. If you MUST install a workstation in the vertical position make sure that the left side vents are toward the floor, there is at least three inches between the floor and the vents, and most important of all make sure that NONE OF THE VENTS ARE BLOCKED. Steve Batsford Research and Development Apollo Computer inc. -- ### User Environment, Apollo Computer Inc. ### Public Access ProLine BBS ### ### {mit-eddie,yale}!apollo!nazgul ### nazgul@pro-angmar.cts.com ### ### nazgul@apollo.hp.com ### (617) 641-3722 300/1200/2400 ### I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. From apollo-request@umix.cc.umich.edu Fri Sep 1 13:22:01 1989 Date: 1 Sep 89 15:57:12 GMT From: rich@EDDIE.MIT.EDU (Richard Caloggero) Organization: MIT EE/CS Computer Facility, Cambridge, MA Subject: csh filename completion problems Message-Id: <12605@eddie.MIT.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Ok, I'm tired of complaining about this, but (flame flame) the SIO driver for SR10 is giving me headaches, specifically with regard to filename completion. When I hit with a unique prefix in the input buffer, it completes the word correctly, but the input buffer is emptied. Thus, if junk.c is the only filename beginning with 'j' in the current directory, then "% ex j" immediately produces another prompt. If I follow the with a control-R (the reprint character), no text is printed, which indeed seems to indicate an empty input buffer. What's going on here! It does work from a vt100 pad, again pointing to the SIO driver as being the culprate!! Please mail responses to me (rich@eddie.mit.edu). I guess I should also say that this problem aside, the SIO support under SR10 is *much* *much* improved over earlier releases!! Hurrah!! :-) -- -- 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 Fri Sep 1 15:19:22 1989 Date: Fri, 1 Sep 89 13:56:38 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8909011756.AA02522@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: Sorry about this ... I'm sorry that I'm clogging the list with personal mail, but all my attempts to reach nvpna1.prl.phillips.nl are failing. Neither MIT's nor U Mich.'s name servers seem to accept the subdomain names, and even though MIT's gateways think they know the routing to the proper IP numbers, /etc/ping fails to get a response. Donal O Coiliean, If your SPE board is still available, I'm interested in obtaining it, and will pay any reasonable shipping charge. My address is: MIT Earth, Atmoshperic, and Planetary Sciences Dept. room 54-527 77 Massachusetts Ave. Cambridge, MA 01239 (617) 253-6180 ====================================================== A note to the mailing list administator ... Would it be possible to list the mailing addresses of the Apollo mailing list subscribers? That way, if a reply to a mail message didn't get through, we could always try the (presumably working) address listed for the person on the mailing list via umix.cc.umich.edu. -- 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 Sep 1 21:20:24 1989 Date: 31 Aug 89 23:40:00 GMT From: lray%uxh.cso.uiuc.edu%ux1.cso.uiuc.edu.uucp@uxc.cso.uiuc.edu Subject: Re: Async. socket i/o Message-Id: <18300012@uxh.cso.uiuc.edu> References: <1308@syma.sussex.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I called the hotline about this some time ago, and they suggested it would be supported at either 10.2 or 11. Leland Ray UIUC - CE Dept. (217) 333-3821 From apollo-request@umix.cc.umich.edu Fri Sep 1 23:25:44 1989 Date: 2 Sep 89 02:00:14 GMT From: weiner%novavax%uflorida%mailrus%wuarchive%brutus.cs.uiuc.edu.uucp@apple.com (Bob Weiner) Organization: Nova University, Fort Lauderdale, FL Subject: Re: Questions about knowledge broader Message-Id: <1457@novavax.UUCP> References: <1989Aug29.161420.2016@quintro.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1989Aug29.161420.2016@quintro.uucp> reb@quintro.uucp (Roger E. Benz) writes: We are currently looking at getting knowledge broaker and would like comments from people who are using it. Apollo sales told us months ago that our DELPHI documentation view software would be upgraded for free to the Knowledge Broker environment but we have not received any updates. I assume this would include only runtime features and not the development environment. Has anybody received such a package? Is this another premature promise? -- Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner (407) 738-2087 From apollo-request@umix.cc.umich.edu Sat Sep 2 03:31:12 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8909020655.AA00286@icaen.uiowa.edu> Date: Sat, 2 Sep 89 01:39:56 CDT Subject: Re: Questions about knowledge broader To: apollo@umix.cc.umich.edu In article <1989Aug29.161420.2016@quintro.uucp> reb@quintro.uucp (Roger E. Benz) writes: We are currently looking at getting knowledge broaker and would like comments from people who are using it. There are 3 different knowledge broker packages that I know of (because we got all 3). 1) Knowledge Broker reader: just the software to read data from an existing KB data base. 2) Knowledge Broker intro kit: The reader and the same set of manuals that were in the Delphi kit. (This is the Delphi upgrade kit, I think that you have to order it.) 3) Knowledge Broker publisher: The reader and the tools needed to create KB manuals. If you get 2) or 3), then you automaticaly have the stuff from 1), so don't bother ordering it. We didn't know this and so ordered all 3 packages. 2) is big, its AA took almost 60 megabytes. 3) has filters so it can import stuff from Interleaf documents. I've loaded the AAs but haven't had time to try it out, so I don't know how well it works. From apollo-request@umix.cc.umich.edu Sat Sep 2 11:59:06 1989 Date: 2 Sep 89 00:57:57 GMT From: weiner%novavax%uflorida%mailrus%wuarchive%brutus.cs.uiuc.edu.uucp@apple.com (Bob Weiner) Organization: Nova University, Fort Lauderdale, FL Subject: Bug in registry merge command Message-Id: <1456@novavax.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu After using a network with an SR9.7 registry and an SR10 registry for six months, we decided to merge the two into a writable SR10 registry. The process failed miserably, even wiped out our SR10 registry once. Then Apollo tells us there is a bug in the registry merge command. Shouldn't they have known about this before August 1989? Haven't people around the world tried to do this already and run into problems? We spent a week on this before anyone from Apollo (an SE was helping) was able to tell about the bug. Does anyone know the story? -- Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner (407) 738-2087 From apollo-request@umix.cc.umich.edu Sat Sep 2 15:16:59 1989 Date: 31 Aug 89 01:33:46 GMT From: troy%mr_plod.cbme.unsw.oz.au%usage%basser%metro%otc%murtoa.cs.mu.oz.au%munnari.oz.au% Subject: Re: vt100 emulation on SR10.1? Message-Id: <410@usage.csd.unsw.oz> References: <133000004@uxa.cso.uiuc.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >From article <133000004@uxa.cso.uiuc.edu>, by gsg0384@uxa.cso.uiuc.edu: >Is there any decent vt100 or xterm emulation software beside the vt100 >that comes with SR10.1? The latter is really a lemon. Is there any patch >program available for vt100? A while ago I had a simple terminal emulator posted to comp.sources.misc, and have since improved it to include most of the features I suggested could be added in the original. It is not vt100 or xterm compatible, but it is more than sufficient for vn, nethack, more, less and just about everything I have tested it with (there is, as I just discovered, a bug with vi). I will submit the new improved version to comp.sources.misc soon. If anybody is curious about the nature of the vt100bug, it lies in the insistance by vt100 to use /dev/ttypa and /dev/ptypa, and not to try any others if it fails. The correct thing to do is to start with ptyp0 and move through to ptypf until one is found which is unoccupied. The error comes about when ptypa has, for some reason, had its modes changed so that it can't be opened, or has been opened by a different process. I consider his particular bug to be outright sloppy programming rather than a bug per se. ---------------------------------------------------------------------------- Troy Rollo troy@mr_plod.cbme.unsw.oz.au Watch out for Gobbledocks - they'll steall all your silicon chippies! From apollo-request@umix.cc.umich.edu Sat Sep 2 19:19:18 1989 Date: 2 Sep 89 20:12:12 GMT From: beech%plus5.uucp@uunet.uu.net (David Beecher) Organization: Plus Five Computer Services, St. Louis Subject: Apollo DN10000 Manual set FOR SALE. Message-Id: <3127@plus5.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Nearly complete set of DN10000 docs for sale. Very low mileage. We also have an additional set of user documentation (i.e. not the hardware ref manuals, etc.). The original cost of this documentation was ~$1700, we can do the deal for $1000 or best offer. We will pay the shipping (UPS Ground). I REALLY want to sell this, please don't hesitate if you are interested. I can be contacted by email at beech@plus5.com or by US mail at: Dave Beecher Washington University Division of Radiation Sciences 510 S. Kingshighway St. Louis, MO 63110 (314) 362-8459 For a quick response, please phone or write as I don't log in to this account very often. I also don't read this newsgroup. Feel free to leave a message on the answering machine if I am not in. From apollo-request@umix.cc.umich.edu Sun Sep 3 01:18:00 1989 Date: 1 Sep 89 22:47:07 GMT From: freedman%ksi.cpsc.ucalgary.ca%calgary%alberta%ubc-cs.uucp@beaver.cs.washington.edu (Dan Freedman) Organization: Knowledge Science Lab, U. of Calgary, Calgary, Canada. Subject: Is anyone happy with IPT's uShare product? Message-Id: <1783@cs-spool.calgary.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Has anyone had success with IPT's uShare product for file/mail/printer sharing between Apollos and Macintoshes? In particular, I am interested in knowing how people feel about performance and reliability. I will post a summary of responses to the network if people mail me replies. Our site found the product to be unreliable (both the 9.7 version and the 10.1 version), and also very slow on an 8mB DN3000. The performance was partucularly slow when accessing files (from the mac) that reside on machines other than the one with the IPT board in it. I would be particularly interested in knowing about anyone who feels that they have had a good experience with the product, so that I can find out if there is something that I am doing wrong. Dan Freedman. Dan Freedman University of Calgary Computer Science Department 2500 University Drive N.W. freedman@cpsc.UCalgary.CA Calgary, Alberta, T2N 1N4 ...!alberta!calgary!freedman From apollo-request@umix.cc.umich.edu Sun Sep 3 03:15:59 1989 Date: 1 Sep 89 17:49:17 GMT From: denis%vlsisj%practic%leadsv%pyramid%nsc%csi%bridge2.uucp@apple.com (/) Organization: VLSI Technology Inc., San Jose, CA Subject: what is the code for a shifted mouse press/release Message-Id: <15303@vlsisj.VLSI.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does anyone know what the key code for shifted mouse button presses and releases are? I looked in /usr/include/apollo/kbd.h but could only find the unshifted codes. I am using sr10.1. Thanks... -- Denis Bohm (usenet: decwrl!vlsisj!denis) (internet: vlsisj!denis@decwrl.dec.com) From apollo-request@umix.cc.umich.edu Sun Sep 3 07:17:25 1989 Date: 2 Sep 89 20:43:04 GMT From: dataxpress%cup.portal.com%portal.uucp@uunet.uu.net (John Philip Eurich) Organization: The Portal System (TM) Subject: Re: Pascal on Apollo Message-Id: <21795@cup.portal.com> References: <8908301312.AA03624@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Reply to Dave Erstad's comment: > I've used Professional Pascal (from Metaware) on the Daisy platform > and generally found it to be low quality. Things like compiler > crashes with useful messages like "Dynamic array allocation/ > reallocation failed" (The compiler's internal arrays, not one > of mine). We have not seen this problem while using PP on the Apollo, VAX/VMS, VAX/Ultrix , Sun3 or Sun4. I believe this message occurs when the compiler has run out of virtual memory. John Eurich From apollo-request@umix.cc.umich.edu Sun Sep 3 09:17:08 1989 Date: 21 Aug 89 19:21:10 GMT From: goldfish%cspolo%clyde%mcgill-vision.uucp@BLOOM-BEACON.MIT.EDU (Paul Goldsmith) Organization: Concordia University, Montreal Quebec Subject: Re: dn10000 registry unavailable, etc .... Message-Id: <1110@clyde.Concordia.CA> References: <8908190242.AA09613@lnic1.hprc.uh.edu>, <419@apcitor.tor.apollo.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <419@apcitor.tor.apollo.com> greg@apcitor.tor.apollo.com (Greg Foisy) writes: > Could people on the net please send me some e-mail and let me know > if it is worth their while if I post the index for the patch tapes > once a month so that people could se what patches are availble. This > is not per say my responsibility at apollo, however, I feel it might > be helpful to those on the net if they were more aware of the patches > that could be obtained. > > Greg Foisy Here Here Greg. Count my vote as a YES! > Of course, these views are mine and mine only. They do not in any way > reflect the thoughts of apollo, Hewlett-Packard, or management. Pity your views are not held by your employer. (maybe you could get promoted to a policy making position :-) -Goldfish goldfish@concour.concordia.ca - Goldfish From apollo-request@umix.cc.umich.edu Mon Sep 4 01:19:03 1989 Date: 4 Sep 89 04:48:04 GMT From: shipley%riki.berkeley.edu%agate.uucp@ucbvax.Berkeley.EDU (Pete Shipley) Organization: Processed People for a Processed America Subject: Connecting a LaserWriter to a Apollo Message-Id: <1989Sep4.044804.2416@agate.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu How the &$$%#^% does one connect a Apple LaserWriter to a 4500 (or a 3500) I it looks like nomatter what I set in the /etc/remotes file the system will always use the 8th bit while communicating with the LaserWriter. I can get a PC to talk to the apollo and the PC to talk to the LaserWriter but I can't get the Apollo to talk to the LaserWriter. Please resond with any infomation you have. (cable pinouts, printcap enteries, /etc/remote enteries, etc.... ) Pete Shipley: email: shipley@berkeley.edu Flames: cimarron@postgres.berkeley.edu uunet!lurnix!shipley or ucbvax!shipley or pyramid!hippo!{ root peter } Spelling corections: /dev/null Quote: "Anger is an energy" From apollo-request@umix.cc.umich.edu Mon Sep 4 11:21:33 1989 Date: 3 Sep 89 21:30:15 GMT From: danny%idacom%alberta%ubc-cs.uucp@beaver.cs.washington.edu (Danny Wilson) Organization: IDACOM Electronics Ltd., Edmonton, Alta. Subject: Apollo Floor stand Message-Id: <719@idacom.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu For those who have been arguing how to stand a node on its end. The logo panel on the front of the machine (which says 'Apollo' or 'Mentor' etc, and has the leds on the it) can have to positions. By pushing in slightly, it is possible to rotate 90-deg to the right. Therefore, we can assume that the node is designed to either lie flat or have the tape drive -up-. This example is for a DN30x0 and it is logical to assume it can be also applied to a DN35x0. -- Danny Wilson IDACOM Electronics danny@idacom.uucp Edmonton, Alberta {att, watmath, ubc-cs}!alberta!idacom!danny C A N A D A From apollo-request@umix.cc.umich.edu Mon Sep 4 15:18:07 1989 Date: 30 Aug 89 00:51:51 GMT From: jimr%extro%natmlab%ipso%metro%otc%murtoa.cs.mu.oz.au%munnari.oz.au%uhccux.uucp@ames.arc. (Jim Richardson [ext 2232]) Organization: Uni Computing Service, Uni of Sydney, Australia Subject: Problem with DPCI Token Ring in XT PCs Message-Id: <581@extro.ucc.su.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have been trying to use a token ring board in a variety of XT PC clones, without success. The RINGDIAG diagnostic in the Domain/Personal Computer Interconnect (DPCI) package always gives the message "No ring board found". We have tried both the alternatives for the jumper settings on the board, and are running DOS 3.10 or 3.2. The board works fine on our ATs (provided we slow the clock speed down; we also did better when we found out that DPCI on the PC turns passwords to upper-case, so your Apollo password cannot contain lower-case letters :-( ). The DPCI manual says that the token ring board will work in either ATs or XTs. Has anyone anywhere succeeded in using a token ring board and DPCI in an XT? If so, please pass on any useful tricks or hints. Thanks in advance. --- Jim Richardson Department of Pure Mathematics, University of Sydney, NSW 2006, Australia UUCP: ...!uunet!munnari!summer.su.oz!jimr ARPA: jimr%summer.su.oz@uunet.uu.net ACSNET, CSNET: jimr@summer.su.oz From apollo-request@umix.cc.umich.edu Tue Sep 5 01:18:04 1989 Date: 4 Sep 89 14:40:19 GMT From: rmillar%leif%garfield.uucp@uunet.uu.net Organization: Computing Services, Memorial University. St.John's Nfld, Canada Subject: Is SAS on Apollo's??? Message-Id: <14661@kean.mun.ca> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does anyone have SAS (Statistical Analysis System) running on an Apollo DN10000 and/or DN2500? We are considering a configuration with a multiple CPU DN10000 and a dozen DN2500's. Apollo claims that SAS runs under their Aegis operation system and that it is available on both the DN10000 and DN2500. The people we've talked to at SAS have never heard of Aegis! So..... what's the score, is SAS running out there on Apollo's? If so, I'd appreciate any relevant comments regarding its reliability and any problems that have been encountered, particularly with regard to the need to have two copies of SAS (one for the DN10000 and another for the DN2500's). Thanks, Russell Millar, Dept of Fish and Oceans, St John's, Newfoundland. From apollo-request@umix.cc.umich.edu Tue Sep 5 09:25:15 1989 Date: 5 Sep 89 09:41:01 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: Re: Sorry about this ... Message-Id: <672@prles2.UUCP> References: <8909011756.AA02522@richter.mit.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8909011756.AA02522@richter.mit.edu> krowitz@RICHTER.MIT.EDU (David Krowitz) writes: >I'm sorry that I'm clogging the list with personal >mail, but all my attempts to reach nvpna1.prl.phillips.nl David, I have received a lot of mail messages from you over the last few weeks but it would appear that you have not received my replies. >If your SPE board is still available, I'm interested >in obtaining it, and will pay any reasonable shipping >charge. My address is: I have tried several to explain via mail, but the long and the short of it is no, our spare SPE boards have at this stage gone back to Apollo. 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 Sep 5 11:29:14 1989 Date: 5 Sep 89 01:20:02 GMT From: vanden%studsys%marque%csd4.csd.uwm.edu%cs.utexas.edu%usc.uucp@ucsd.edu (vandenberg) Organization: Marquette University - Milwaukee, Wisconsin Subject: Mailing List Message-Id: <605@studsys.mu.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If the party responsible for the Apollo mailing list monitors this group I would appreciate it if you could add me to the list. Thanks ------ Tom Vandenberg {..uunet..uwvax!uwmcsd1..}!marque!studsys!vanden vanden%studsys@marque.UUCP {..uwvax..arpa..}!studsys.mu.edu!vanden Disclaimer - No one knows what I do, not even me. 43 4 58 N / 87 55 52 W From apollo-request@umix.cc.umich.edu Tue Sep 5 11:35:12 1989 Date: Tue, 5 Sep 89 10:32:11 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8909051432.AA07921@richter.mit.edu> To: apollo@umix.cc.umich.edu, jimr%extro%natmlab%ipso%metro%otc%murtoa.cs.mu.oz.au%munnari.oz.au%uhccux.uucp@ames.arc. Subject: Re: Problem with DPCI Token Ring in XT PCs We have a ringnet board in an an XT clone here. It's been a while since we put it in, but it's working fine. If I remember correctly, we had a couple of porblems during the installation. The first was that the hard disk controller on the XT uses the primary address for the ringnet controller. The second was that our multi-function board (time-of-day clock, memory, and monochrome diskplay) also interferred with the ringnet board. It turned out that we had to disable the time-of-day clock in order to get the ringnet board to 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) From apollo-request@umix.cc.umich.edu Tue Sep 5 13:22:00 1989 Date: 5 Sep 89 14:51:57 GMT From: rich@EDDIE.MIT.EDU (Richard Caloggero) Organization: MIT EE/CS Computer Facility, Cambridge, MA Subject: Looking for postscript to impress conversion tool Message-Id: <12622@eddie.MIT.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu ... does it exist? We run SR10.1. -- -- 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 Tue Sep 5 13:31:08 1989 Date: 5 Sep 89 14:55:34 GMT From: paul%kuhub.cc.ukans.edu%wuarchive%brutus.cs.uiuc.edu.uucp@apple.com (Craig Paul) Organization: University of Kansas Academic Computing Services Subject: Want execute only, no read permission. How? Message-Id: <10624@kuhub.cc.ukans.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Using Aegis 9.7.1 we'd like to give permission to execute only without enabling read permission. The ACLs seem to support this, theoretically, but actually don't. Any hints? Is this fixed in 10.1? Thanks! From apollo-request@umix.cc.umich.edu Tue Sep 5 15:22:23 1989 From: Christopher J Fomon Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8909051804.AA02317@icaen.uiowa.edu> Date: Tue, 5 Sep 89 13:03:50 CDT Subject: IPT server To: freedman@cpsc.UCalgary.CA, apollo@umix.cc.umich.edu, apollo-request@umix.cc.umich.edu The University of Iowa College of Engineering Iowa Computer Aided Engineering Network (ICAEN) Respondent: Christopher Fomon cjfomon@icaen.uiowa.edu Objective: To centralize application software distribution for student laboratories. Current setup: 110 Apollo Workstations. 2400 user accounts. 150 Apple Macintosh Computers. ---> Only 60 Macintosh computers Networked to Apple Local area network. Software/Hardware in use as of September 6, 1989 Host Server: DN4000 with 8Meg RAM and 348Megabyte hard disk storage. Host has about 100Megs free for paging. Token ring distributed network. OS: SR 9.7 with BSD 4.2 IPT's office automation file server. IPT dual port AppleTalk card. Six volumes containing 100 Megs of software applications and documents. Network Twisted pair wire as backbone with RJ11 phone jacks. Shiva Netbridges used to isolate local printing from twisted pair LAN backbone. 8 Macs and 4 printers per isolated side. CompuNet (PhoneNet style connector boxes) Client Macintosh SE Dual drive computers with 2.5Meg of RAM. RAM disk AppleShare workstation system. Clients have AppleTalk port connected to LAN. Clients have AppleTalk ImageWriters available as a local resource. Clients have modem port connected to Gandalf Paxc Data Switch (9600 and 19200 baud rate available for private point to point Campus computer service. This includes Apollo Domain.) Results: Pros: Centralized administration of software applications and documents acheived. Workstation System RAM Disk (Ramdisk+ from Roger Bates) compatible with AppleShare. MultiFinder Compatible. Loading time of applications similar to MacServe LAN with Mac SE as host. (MacServe comparision of 1 Host SE and 5 client SE) Loading time of remote storage space marginally slower, add 2 secondsto base time. Access of DOMAIN registry for login ids and passwords. Some software availble with multi-execution lic. Example: MacWrite II. Plug and go network wiring scheme. Technical support from IPT informative. Some sample test executions. 15 seconds to open a ten Megabyte volume. 18 seconds to open MacWrite v4.6 (335K, config at 224K). 30 seconds to open Cricket Graph v1.2 (348K, config at 512K). 35 seconds to open Microsoft Word 4.0 (1,144K, config at 1024K). 42 seconds to open MacDraw II (585K with config for 800K). Cons: Protection bit not availble on IPT server. Bug in registry release mechanism. uTERM to slow to use, and not necessary for this site. --->NCSA Telnet is used in some parts of the building. --->Columbia Kermit used on modem lines. uDisk was not used, local storage on floppies encouraged instead. SR10 version is using Unix Sys 5, instead of bsd 4.2. Some applications do not execute properly from the server. Technical support from IPT slow. Documentation on IPT server files minimal. Alteration in the system to decrease loading time on the server. 1) Prevent users from creating private disk storage on Apollos. Encourage floppy storage. 2) Prevent terminal connections over LAN. Substituted traditional modem line connects. 3) Eliminate most host printing for local printing within user LAN zone. 4) High speed host with large RAM size and paging area. 5) Installed LAN bridges for AFP and PAP routing. 6) RAM disk workstation system disk to off load all system overhead. Comments: The slow rate of data enchange over the Apple LAN appears to be the limiting factor to the user interface. Once applications are loaded into memory students do not notice the LAN connection. User comments are positive indicating that access to all application from any location is more important than speed. Administration of dual registries would have terminated this product. CAP would have meant greater investment of administrative and programming time. Although some products will have to be replaced, centralized administration of Macintosh programs will save overall deployment times. If I was implementing this resource again, I would still choose the IPT fileserver. Because of price and support as well as the DOMAIN OS tie in. From apollo-request@umix.cc.umich.edu Tue Sep 5 17:27:23 1989 Date: Tue 5 Sep 89 14:02:58-PST From: Steve Albrecht Subject: Re: Apollo Floor stand To: danny%idacom%alberta%ubc-cs.uucp@beaver.cs.washington.edu Cc: apollo@umix.cc.umich.edu Message-Id: <621032579.20000.ALBRECHT@CALIPH> In-Reply-To: <719@idacom.UUCP> Mail-System-Version: Danny Wilson of IDACOM Electronics Ltd., Edmonton, Alta. (danny@idacom.uucp) writes: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Noting that my previous message has my logical pmdf_from prepended to an internet address, we discovered that ANU news knows about pmdf_from now, and will use news_from as a default if news_from is provided. In any case, the correct address for the posting is paul@kuhub.cc.ukans.edu Thank you. From apollo-request@umix.cc.umich.edu Tue Sep 5 19:28:43 1989 Date: 5 Sep 89 20:32:57 GMT From: riner%avsd.uucp@ucbvax.Berkeley.EDU (John Riner) Organization: AMPEX Corporation, Redwood City, CA Subject: Re: Apollo Floor stand Message-Id: <2039@avsd.UUCP> References: <719@idacom.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu For those of you trying to rotate the label on a DN35x0 or 45x0 you can give up now. Too bad though it was a nice feature. From apollo-request@umix.cc.umich.edu Tue Sep 5 21:19:51 1989 Date: 5 Sep 89 23:24:18 GMT From: kcantrel%digi%attctc.uucp@ames.arc.nasa.gov (Keith Cantrell) Organization: none Subject: Re: Async. socket i/o Message-Id: <219@digi.UUCP> References: <1308@syma.sussex.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1308@syma.sussex.ac.uk> andrewn@syma.UUCP (Andrew D Nimmo) writes: > > Is, as is implied in the 'Programming Enviroment Reference' manual, >the use of asynchronous socket i/o (using fcntl, select and signal) not >possible under SR10.1 (and SR10.0.p)? If this is true when will it be >implemented, or does an update exist to patch this potentially serious ommision? > My problem stems from an fcntl call returning the error 'No such file >or directory' when applied to a known (UNIX) socket - although this is a valid >error, it does not appear to be a valid fcntl error. > I was receiving this error too when I was tring to put a socket into non-blocking mode. The problem turned out to be that I was not doing a fcntl(fd, F_GETFL, 0) before I was doing the fcntl(fd, F_SETFL, FNDELAY). The code segment should be something like: if((a = fcntl(fd, F_GETFL, 0)) == -1) { perror("error"); exit(1); } a |= FNDELAY: if(fcntl(fd, F_SETFL, a) == -1) { perror("error"); exit(1); } This should clear up your 'no such file or directory' error. One thing to note, if you set the environment variable "APOLLO_STATUS" to "TRUE" before you executre a program that makes a calls to "perror", you will get much better error messages. ----------------------------------------------------------------------- Keith Cantrell Phones: hm: 214-492-1088 Apollo Computer wk: 214-519-2399 @ DSC A Subsidiary of Hewlett-Packard USMAIL: EMAIL: 2100 Sonata Ln cantrell@attctc.DALLAS.TX.US Carrollton TX 75007 or ...!attctc!digi!kcantrel My opinion is my own and does not reflect the view of my employer. ----------------------------------------------------------------------- From apollo-request@umix.cc.umich.edu Wed Sep 6 09:23:31 1989 Date: 6 Sep 89 03:59:16 GMT From: steve%simon%obdient%laidbak%att.uucp@ucbvax.Berkeley.EDU (Steven E. Piette) Organization: ACT, Inc., Dank Dark Cave, Algonquin, IL. Subject: Re: OS Updates and Solution Suppliers Message-Id: <358@simon.UUCP> References: <8908181731.AA15625@umix.cc.umich.edu>, <45458f3d.b617@bear.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <45458f3d.b617@bear.engin.umich.edu>, stealth@caen.engin.umich.edu (Mike Peltier) writes: > In article <8908181731.AA15625@umix.cc.umich.edu> FERGUSON@TMASL.EXXON.COM writes: > >Whenever Apollo makes these radical OS changes, there's a HUGE (capital H) > >time lag before the third party software/peripheral vendors bother to > >come out with a new revision of their support software. For instance: > > [examples deleted] > > Perhaps the developers need to be briefed ahead of time about the impending > changes to the operating system, and have the opportunity to use and explore > the new verion before it is released to the public, instead of at the same > time. Software revision takes time, I don't think it's just a matter of > the developers sitting on their duffs all day. > Apollo did just that in preperation for the release of SR10. Back in August 2 years ago (Or was it three) they held one of the first conferences on SR10 for the solution suppliers as part of the ATQP. Many of the third partys had already had alpha and beta copies of SR10 and were busy porting for the DN1000 which required SR10 as a base level OS. Included were a handfull of SE's from across the world who were trained along with the third partys. We then provided many of the non-disclosure presentations and early field technical support on both SR10 and the DN1000. So, at least in the case of SR10 many software developers had pre-release software, time in the porting centers, and access to the engineers. What I say happen in many cases is that a vendor's development schedule didn't line up well with the new software release schedule because of other hardware platforms they supported, quality control cycles, and limited resources. While I was at Apollo one of the biggest fustrations was customers who were still running old releases of software, not just one release back mine you, Now some was due to third party software issues, but lots were just due to the same issues the third partys had; porting their software, QA, resources. It was really difficult to remember the bugs and try and help these people without sounding like a broken record in suggesting they upgrade. I mean does anyone remember when the current 9.7 version of DOMAIN/IX (the 9.5 tape) was released. (We're talking years now, though one would think in all that time Apollo could have fixed all the bugs :-)) Before laying all the blame on Apollo let me ask are all of you running at least one system with the latest version of software for testing and porting?. My guess is no given the amount of 9.7 and whats in 10.x types of questions seen in this newsgroup. Again, Early access to software for the solution suppliers is only part of the problem, They need external pressure in the form of customers requiring them to maintain current releases of their software in order to sell it. -- Steven E. Piette Applied Computer Technology Inc. UUCP: {smarthost}!simon!steve 1750 Riverwood Drive INET: steve@simon.CHI.IL.US or spiette@SUN.COM Algonquin, IL 60102 ------------------------------------------------------------------------------- From apollo-request@umix.cc.umich.edu Wed Sep 6 15:21:06 1989 Date: 6 Sep 89 13:18:00 GMT From: jcz%sas%rti.uucp@mcnc.org (John Carl Zeigler) Organization: SAS Institute Inc, Cary NC Subject: Re: Is SAS on Apollo's??? Message-Id: <1194@sas.UUCP> References: <14661@kean.mun.ca> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu rmillar@kean.mun.ca asks: Does anyone have SAS (Statistical Analysis System) running on an Apollo DN10000 and/or DN2500? We are considering a configuration with a multiple CPU DN10000 and a dozen DN2500's. Apollo claims that SAS runs under their Aegis operation system and that it is available on both the DN10000 and DN2500. The people we've talked to at SAS have never heard of Aegis! I am amazed that the people you talked to at SAS Institute have never heard of AEGIS, because we have been using Apollos to develop Version 6 since 1985 - we now have over 300 Apollo Nodes on our ring. (Since we have no production version of SAS for Apollos, the sales people may not be aware of it . . . ) We have not developed a production system for Apollos before now because it was felt the market for the SAS System on Apollos consisted of the Institute itself, but that has changed. We plan to provide support for Apollos DN3000 series machines with 68020 or better with a 68881 or better floating point co-processor in Release 6.07. This release will support X Windows (not DM) under the SR10.2 operating system. We do not have any current plans to support DN2xxx or DN10xxxx machines. Release 6.07 is scheduled for mid-1990. So..... what's the score, is SAS running out there on Apollo's? If so, I'd appreciate any relevant comments regarding its reliability and any problems that have been encountered, particularly with regard to the need to have two copies of SAS (one for the DN10000 and another for the DN2500's). Thanks, Russell Millar, Dept of Fish and Oceans, St John's, Newfoundland. -- --jcz John Carl Zeigler Manager, UNIX Host R&D SAS Institute Inc. Cary, NC 27512 (919) 467-8000 ...!mcnc!rti!sas!jcz From apollo-request@umix.cc.umich.edu Wed Sep 6 15:29:24 1989 Date: 6 Sep 89 15:18:46 GMT From: larss%draken%kth%sunic%mcsun.uucp@uunet.uu.net (Lars Schylberg) Organization: Royal Institute Of Technology, Stockholm, Sweden Subject: Xwindows X11R3 Message-Id: <1566@draken.nada.kth.se> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I'm running Apollos release of X11R2 on our machines right now. Today I realised that a software that I'm porting is needing some routines that are in X11R3. Could anyone give some hints how much work it is to install X11R3 the official MIT release on my DN3500 if I bring home over the net. We are running SR 10.1. Lars. -- Lars Schylberg Email: larss@fmi.kth.se (Internet) Department of Photogrammetry larss@sekth.bitnet (Bitnet) Royal Institute of Technolgy Tel. +46 8 790 86 33 (office) S-100 44 STOCKHOLM, SWEDEN Fax. +46 8 10 91 99 From apollo-request@umix.cc.umich.edu Wed Sep 6 17:22:48 1989 Message-Id: <8909062019.AA16784@uunet.uu.net> Date: Wed, 6 Sep 89 16:17:40 edt From: matthew barnes To: apollo%umix.cc.umich.edu%uunet.uucp@uunet.UU.NET Subject: Help with screen 2.0 Hello, I am trying to get a copy of Screen 2.0 for my Apollos. I tried to get a copy of the source from netlib@mcs.anl.gov, but it doesn't seem to be there. I was wondering if you could either tell me where else I can get it (I don't have access to ARPANET), or if you feel generous today (I hope), could you send the sources my way....?? Thanks in advance for any help!! Matthew Barnes Structural Dynamics Research Corporation 2000 Eastman Drive Milford, Ohio 45150 (513) 576-2015 ...uunet.uu.net!sdrc!crmatt From apollo-request@umix.cc.umich.edu Wed Sep 6 21:18:44 1989 Date: 4 Sep 89 23:48:29 GMT From: troy%mr_plod.cbme.unsw.oz%usage%basser%metro%otc%murtoa.cs.mu.oz.au%munnari.oz.au%uhccux. (Troy Rollo) Organization: troy Subject: Using the SPE option under SR10.1 Message-Id: <415@usage.csd.unsw.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu How do you get the SPE option working under SR10.1? I have the SR9.7 versions of the SPE software, but that doesn't appear to work under SR10.1. All I get when I try to use sio2 and sio3 is "unable to open stream - device not implemented (stream manager/IOS)" _______________________________________________________________________________ troy@mr_plod.cbme.unsw.oz.au Watch out for Gobbledock's They'll steal all your silicon chippies. From apollo-request@umix.cc.umich.edu Wed Sep 6 21:25:02 1989 Date: 5 Sep 89 02:29:23 GMT From: troy%mr_plod.cbme.unsw.oz%usage%basser%metro%otc%murtoa.cs.mu.oz.au%munnari.oz.au%uhccux. (Troy Rollo) Organization: troy Subject: My terminal emulator got smashed Message-Id: <416@usage.csd.unsw.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If anybody was waiting for my latest terminal emulator, don't bother. It just got crunched due to a severe lack of communication on the machine it was stored on. All that's left is the termcap file, which I had stored here so I could use it when using telnet.... To give you an idea of what it was like, here's the termcap file: # # Termcap file for my news reading emulator # # run tm, then set: # # MORE=-c # TERM=this # TERMCAP=$HOME/termcap # th|this|this emulator:\ :cm=\E%r%+ %+ :cl=\14:li#24:co#80:bs: dt|delterm|delta terminal emulator:\ :cm=\EC%r%+ %+ :cl=^L:li#24:co#80:bs:\ :bl=^G:cr=^M:ct=^ET :da:db:do=\E[d:\ :ho=\EC :kb=^H:kD=\E[D:kd=\E[d:\ :kF=\E[F:kI=\E[I:kL=\E[L:kl=\E[l:kN=\E[N:\ :kP=\E[P:kR=\E[R:kr=\E[r:ku=\E[u:le=\E[l:\ :md=\EF\047:me=\EF :mr=\EF\056:ms:nd=\E[r:\ :so=\EF\047:se=\EF :sf=\EU:sr=\ED:uc=_:ul:\ :up=\E[u: This terminal emulator (the delterm emulator) would start first go, every go, was a little slower than vt100, and would allow font changes. How many of you out there would like me to rebuild it? I couldn't be bothered rebuilding it for myself alone.... too much effort, too little time. __________________________________________________________________ troy@mr_plod.cbme.unsw.oz.au Watch out for Gobbledocks The Resident Fascist They'll steal all your silicon chippies. From apollo-request@umix.cc.umich.edu Wed Sep 6 23:18:27 1989 Date: 6 Sep 89 23:44:43 GMT From: markl%neptune%amdcad.uucp@ucbvax.Berkeley.EDU (Mark Luedtke) Organization: Advanced Micro Devices, Inc., Austin, Texas Subject: Re: Deteriorating Media Message-Id: <1082@neptune.AMD.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have a dsp3550 with two 760Mb drives. A couple of weeks ago we had the primary drive replaced as disk data check errors were occuring at an increasing frequency. When we went to load the user data back, we found our backups were not complete, so we had our Mentor representative install the disk in one of his machines and dump a tape (they use cartridge almost exclusively). Well, after getting the tape here, we couldn't read beyond some tape error to get at the two projects we need restored. The rep then had problems writing another tape. Now the drive is reinstalled here, but it won't mount since the logical volume header appears to be corrupted. Question #1: Does anyone know of a way to get at the data on the tape (probably the better copy)? RBAK dies at some location and will not find anything further, but if I could get it to start looking further down, I should be able to access the data. An index, using RBAK, will pass the bad spot, but reading won't and using '-f cur' tells me that the current location is unknown. Can I use RWMT in raw mode to build a file then RBAK from that file? Any options at all for the tape? Question #2: I'm sure most of the data is still on the disk, but how can I get to it? Using fixvol I can get make the PV ok, but the LV and ALV are trashed (disk data check again). I also tried using UNIX mkdisk with mount and dd, but dd only read what appeared to be some header information then quit with no error message; mount claimed the volume was in use. Any suggestions for dumping the disk? We are running 9.7.5 and the machine is mounted diskless off a dn3550. We also run BSD4.2, and I could probably install SYS V if it would help. Any help is appeciated. Mark Luedtke markl@neptune.amd.com (512)462-5278 Disclaimer (?) My spelling is a work of art From apollo-request@umix.cc.umich.edu Thu Sep 7 11:24:45 1989 Date: Thu, 7 Sep 89 10:04:04 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8909071404.AA13058@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: Yet another SR10.1 problem Here's a new one ... I just tried to boot one of my DN3000's (normally running SR9.7.1) off of a DN460 running SR10.1 so I could test out some DN3000 specific software under SR10. I copied the /sau8 directory from the AA machine over to the DN460 and then booted the DN3000 diskless off of the DN460. The machine booted just fine, but when I try to login it pops up my two initial windows and they are still-born. I never get a shell prompt, typing control-Q gets me a "level 2 process not found" message, and typing control-N closes the window. Doing a "cp /com/sh" or a "cp /bin/csh" DM command also pops up a dead window. So ... just for tricks ... I tried booting my DN560 (my AA machine) off of the DN460. I copied the /sau5 directory over and then tried to boot the machine. Much to my surprise, it would not boot. It starts loading the OS and then gets a "boot error: uid request failed" message just after the low, high, and start addresses are printed. Are these known bugs? Are there known fixes? Am I just doing something stupid? -- 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 Sep 7 15:25:49 1989 Date: Thu, 7 Sep 89 14:02:03 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8909071802.AA13716@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: More SR10 madness Ok, here's another one ... from my SR9.7 node I can "crp" onto a diskless node running SR9.7. From my SR10 node I can "crp" onto the same diskless machine *if* I am logged in as krowitz.sys_admin, but not if I am logged in simply as krowitz.my_own_group. I get an "insufficient rights" error when I am not sys_admin. Anyone know which set of acls on which files is causing this? -- 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 Sep 7 15:31:53 1989 Date: 7 Sep 89 15:43:18 GMT From: reb%quintro%tiamat.uucp@uunet.uu.net (Roger E. Benz) Organization: none Subject: Re: My terminal emulator got smashed Message-Id: <1989Sep7.154318.22063@quintro.uucp> References: <416@usage.csd.unsw.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <416@usage.csd.unsw.oz> troy@mr_plod.cbme.unsw.oz (Troy Rollo) writes: > >If anybody was waiting for my latest terminal emulator, don't bother. >It just got crunched due to a severe lack of communication on the >machine it was stored on. > >How many of you out there would like me to rebuild it? I couldn't >be bothered rebuilding it for myself alone.... too much effort, too >little time. > I would be interested in the software. -- 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 Sep 7 20:42:04 1989 Date: Thu, 7 Sep 89 15:44:38 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8909071944.AA13986@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: /com/sh programming I want to write an Aegis shell script that checks if a previously executed command completed correctly. If I remember correctly, programs which run to completetion return the status code PGM_$OK. Does anyone know how I can test for this within a shell script? -- 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 Sep 7 20:46:10 1989 Date: Thu, 7 Sep 89 16:45:23 EDT From: crh@apollo.eng.ohio-state.edu (Charlotte Hawley) Message-Id: <8909072045.AA01686@apollo.eng.ohio-state.edu> To: apollo@umix.cc.umich.edu, krowitz@richter.MIT.EDU Subject: Re: More SR10 madness Regarding the crp error - check the access rights on /dev/crp's There is a bug in SR10 that causes these to get messed up. From apollo-request@umix.cc.umich.edu Fri Sep 8 00:40:32 1989 Date: 7 Sep 89 02:46:46 GMT From: petem%sdipl%usage%basser%metro%otc%murtoa.cs.mu.oz.au%munnari.oz.au%uhccux.uucp@ames.arc. (Peter Mason) Organization: sdi Subject: Re: Using the SPE option under SR10.1 Message-Id: <14@sdipl.oz> References: <415@usage.csd.unsw.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <415@usage.csd.unsw.oz> troy@mr_plod.cbme.unsw.oz (Troy Rollo) writes: > > How do you get the SPE option working under SR10.1? I have >the SR9.7 versions of the SPE software, but that doesn't appear to >work under SR10.1. All I get when I try to use sio2 and sio3 is Yes we've had same problem since installation in March. APOLLO locally report that SR10.2 fixes the problem, but are no more helpful than that. From apollo-request@umix.cc.umich.edu Fri Sep 8 04:40:29 1989 Message-Id: <8909080800.AA09969@umix.cc.umich.edu> Date: Thu, 07 Sep 89 15:23:17 EDT From: Scott Ferguson Subject: Please Change my Address on the mailing list To: apollo@umix.cc.umich.edu I have a new address, and would like this mailing list to send there from now on. It is: srfergu@erenj.bitnet It's nice & cryptic, like all addresses, but it's where I am. Thanks, and sorry to bother everyone. Scott Ferguson Exxon Research & Engineering Annandale, NJ 08801 (201) 730-2339 From apollo-request@umix.cc.umich.edu Fri Sep 8 07:19:13 1989 Date: 7 Sep 89 22:55:56 GMT From: freedman%ksi.cpsc.ucalgary.ca%calgary%alberta%ubc-cs.uucp@beaver.cs.washington.edu (Dan Freedman) Organization: Knowledge Science Lab, U. of Calgary, Calgary, Canada. Subject: Has Apollo announced release dates for new os's Message-Id: <1796@cs-spool.calgary.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Has Apollo announced release dates for SR10.2 and/or SR11, and have they released a list of enhancements in this software? How about a release date for OSF/Motif? When will open dialog support motif? Is Apollo developing software for using postscript as a display language? Is NeWS being ported to the Apollo? Dan Freedman University of Calgary Computer Science Department 2500 University Drive N.W. freedman@cpsc.UCalgary.CA Calgary, Alberta, T2N 1N4 ...!alberta!calgary!freedman From apollo-request@umix.cc.umich.edu Fri Sep 8 07:24:21 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8909080942.AA00712@icaen.uiowa.edu> Date: Fri, 8 Sep 89 04:20:43 CDT Subject: Re: Yet another SR10.1 problem To: krowitz@richter.MIT.EDU Cc: apollo@umix.cc.umich.edu Re the diskless node booting failure with "boot error: uid request failed" error: Yes there is a problem with netman at sr10.1 and diskless node booting. The really strange part of it is it only occurs when you do a forced partnering. If you partner via the "diskless_list" file then things work OK. IE the problem only shows up when you use the MD command "DI N node-id" and then try to boot. If you edit the "diskless_list" file on the sr10 disked node and then let the diskless node auto-partner then its OK. I've found 3 different work-arounds for this problem. 1) Just use the "diskless_list" and auto-partner. If you can't do that, or don't want to because it's a temporary partnering, then there are 2 options. 2) do the "DI N node-id", then do a "LD", and then try to boot. For some strange reason, doing the MD command "LD" to get a directory listing from the disked node will make the boot succeed (most of the time). IE: > DI N 12345 > LD > EX DOMAIN_OS 3) If things are really tough, (IE the "LD" trick won't do it), then run netman in debug mode on the disked node. For some strange reason if netman is running in debug mode then it's better behaived. To run netman in debug mode, invoke it in a window and give it the "-db" option. Be aware, if you have this booting problem then it's going to leave some strange trash processes on your disked node after the boot request fails. After you get the "boot error: uid request failed" error, do a "/com/pst -l1" command on the disked node. You'll see some strange "level 1" process appear. An additional one of these will appear for each failed boot attempt. I don't know what the ramifications of these things are but I don't like them. I'd reboot the disked node to get rid of them if I were you. Dave Funk From apollo-request@umix.cc.umich.edu Fri Sep 8 07:27:35 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8909080919.AA00695@icaen.uiowa.edu> Date: Fri, 8 Sep 89 04:02:07 CDT Subject: Re: More SR10 madness To: krowitz@richter.MIT.EDU Cc: apollo@umix.cc.umich.edu Re the "crp insufficient rights" error under sr10: You have an ACL problem on `node_data/dev for the target machine. 1) "/dev" must be world writeable for "crp" to work, at sr10, as the SPM creates a new "/dev/crpXX" mailbox for each crp session. Note that at sr9.7 the "crp_mbx001" was created in `node_data, so the world didn't need "write" permissions to "`node_data/dev", now at sr10 it does need "w" on "/dev" 2) There is a bug in "spmlogin" that causes it to create messed up ACLs on the "/dev/crp00" mailbox, if you "crp" with the "-login" option and then later do it again with "-me". This only happens if you have Unix style inheretance for the inital file ACL on "/dev". The error is a little confusing, but the sequence looks like this: First from SID "anything else" I do a crp to my ".locksmith" SID Then later when I'm logged in as ".locksmith" I do a "crp -me" $ crp -on //is7 -me ?(crp) Can't create remote process - client has no rights to server mailbox (library/MBX manager) $ acl //is7/sys/node_data/dev/crp00 Acl for //is7/sys/node_data/dev/crp00: Required entries dbfunk.%.% prwx- %.locksmith.% -rwx- %.%.none [ignored] %.%.% ----- Extended entry rights mask: ----- Now look at the ACL on "/dev" for that node: $ acl //is7/sys/node_data/dev -all Acl for //is7/sys/node_data/dev: Required entries root.%.% prwx- %.sys_admin.% prwxk %.%.is -rwxk %.%.% -rwxk Extended entry rights mask: ----- Initial (default) acl for directories created under //is7/sys/node_data/dev Required entries For the current process: [from process] [specified by process] dbfunk.%.% [specified by process] [from process] [specified by process] %.locksmith.% [specified by process] %.%.none [ignored] %.%.% [specified by process] Extended entry rights mask: ----- Initial (default) acl for files created under //is7/sys/node_data/dev Required entries For the current process: [from process] [specified by process] dbfunk.%.% [specified by process] [from process] [specified by process] %.locksmith.% [specified by process] %.%.none [ignored] %.%.% [specified by process] Extended entry rights mask: ----- If we change the initial default file ACL for the "/dev" directory, the problems go away. The important thing is to have Aegis style inheretance for the initial file ACL. Try an ACL like: $ acl //is7/sys/node_data/dev -all Acl for //is7/sys/node_data/dev: Required entries root.%.% prwx- %.sys_admin.% prwxk %.%.is -rwxk %.%.% -rwxk Extended entry rights mask: ----- Initial (default) acl for directories created under //is7/sys/node_data/dev Required entries For the current process: [from process] [specified by process] dbfunk.%.% [specified by process] [from process] [specified by process] %.locksmith.% [specified by process] %.%.none [ignored] %.%.% [specified by process] Extended entry rights mask: ----- Initial (default) acl for files created under //is7/sys/node_data/dev Required entries For the current process: root.%.% prw-- %.staff.% -rw-k %.%.none -rw-k %.%.% -rw-k Extended entry rights mask: ----- There is a patch tape out with a new version of spmlogin that is supposed to cure this problem also. However I found that setting the ACLs works just fine. Dave Funk From apollo-request@umix.cc.umich.edu Fri Sep 8 07:33:02 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8909081030.AA00444@icaen.uiowa.edu> Date: Fri, 8 Sep 89 04:58:18 CDT Subject: Re: omniback To: apollo@umix.cc.umich.edu, achille%cernvax%mcvax.uucp@uunet.uu.net WRT posting from achille%cernvax%mcvax.uucp@uunet.uu.net (achille petrilli) > On a, more or less, related argument, I'd like to know if somebody has tested/used > the new backup facility from Apollo, NBS Omniback. I'm interested in hearing any > quirks/problems you had and about its performance. Here's my first pass opinion of Omniback: Its fast, its neat, but its a little rough around the edges. Specifics: OS: sr10.1, Omniback v1.0, Exabyte attached to DN3500 SCSI port. Up side: The concept seems sound. The "work list" and scheduler are usefull powerfull tools. The dialog interface provides usefull progress information. It is fast, doing a "-conc 3" from a bunch of DN3500s with 348 Meg disks, I saw about a 100Kbyte/sec backup rate. Down side: It doesn't have some of the nice features that Workstation Solutions "tbs" product has, such as the index listing depth control. It seems rather fragile. Due to simple problems, that wouldn't have caused wbak to even pause, the Omnibackup of a complete disk crashed. IE the data reader process on the node died so that the backup of that disk was aborted. The backup of the other disks in progress wasn't affected, but the offending disk wasn't backed up. But, out of 8 disks in my backup test, the backup failed on 3 of them. Simple things like an abandoned floppy disk mount point caused the failures. These were things that would cause wbak to report an "object not found" error, but it would continue to back up the rest of the disk. When a backup on a disk failed, it would leave behind a "data reader" process that would then go into an infinite loop and eat up all spare CPU cycles until killed by hand. This is a brand new product and the first version, so a few bugs are to be expected. I've only given it a few tests and havn't tried all modes of operation. In non-concurrent mode it may work better. Once enough bugs are worked out so that it's more reliable, it'll be a good tool. For now though, we are still using wbak. Dave Funk From apollo-request@umix.cc.umich.edu Fri Sep 8 11:20:31 1989 Date: 7 Sep 89 21:52:13 GMT From: edwardm%hpcuhc%hpda.uucp@ucbvax.Berkeley.EDU (Edward McClanahan) Organization: Hewlett Packard, Cupertino Subject: Any DSEE users out there? Message-Id: <2260001@hpcuhc.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Anybody out there in Apollo User Land have experience with DSEE? Forgive me if this has been discussed "ad nasueum" in this notesgroup before... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Edward McClanahan Hewlett Packard Company Mail Stop 47UE -or- edwardm%hpda@hplabs.hp.com 19447 Pruneridge Avenue Cupertino, CA 95014 Phone: (408)447-5651 From apollo-request@umix.cc.umich.edu Fri Sep 8 14:54:20 1989 Message-Id: <8909081831.AA01685@umix.cc.umich.edu> Date: 8 Sep 89 13:20:00 CST From: "DAVE ERSTAD" Subject: Re: Any DSEE users out there? To: "apollo" You bet! There is also a DSEE mailing list - the address escapes me at the moment, but it is in the DSEE manual. Generally, we've been extremely happy with DSEE except for the SR10 conversion - there were a nubmer of undocumented version dependencies ("when we said 9.7 what we really meant was 9.7.0.4") and a couple of glitches in other things which primarily show up when using DSEE. Dave Erstad Principal Design Automation Engineer Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Fri Sep 8 15:01:23 1989 Date: 8 Sep 89 17:15:54 GMT From: zeleznik%cs.utah.edu%wasatch%hellgate.utah.edu%helios.ee.lbl.gov%agate.uucp@ucbvax.Berkeley. (Mike Zeleznik) Organization: University of Utah CS Dept Subject: /etc/server problems Message-Id: <3283@wasatch.utah.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I have a problem with "/etc/server -p file" running shell scripts. It runs them fine if I am root, but if not, /com/sh scripts will work, but /bin/csh ones will not. The simple test scripts are: #!/bin/csh /bin/ls /tmp > /tmp/out #!/com/sh /bin/ls /tmp > /tmp/out /etc/server just returns immediately from the bin/csh script without doing anything, but the /com/sh one works fine. Same on a 10000 and a 3000. I think I must have something locked down funny, but couldn't see any pathnames in /etc/server that would be the cause. Does anyone have any ideas? Thanks, 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 Fri Sep 8 16:51:37 1989 Date: 8 Sep 89 12:46:07 GMT From: ccsmm%gdt%dcl-cs%ukc%mcsun.uucp@uunet.uu.net (Martin Maclaren) Organization: University of Bath, England Subject: /sys5/bin/mkdir Message-Id: <1989Sep8.124607.9025@gdt.bath.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We've SR9.7. Our DOMAIN/IX sys5 mkdir comes as... -rwsr-xr-x 1 root sys 2038 .... mkdir It allows a directory to be created where an Aegis "crd" will not. Is this type of thing common? Maybe we've an old DOMAIN/IX, is it fixed down the line? Martin From apollo-request@umix.cc.umich.edu Fri Sep 8 20:48:55 1989 Date: 8 Sep 89 21:23:31 GMT From: rchrd%well.uucp@apple.com (Richard Friedman) Organization: RCHRD 2855 Telegraph #415 Berkeley CA 94705 Subject: Re: Deteriorating Media Message-Id: <13518@well.UUCP> References: <1082@neptune.AMD.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1082@neptune.AMD.COM> markl@neptune.AMD.COM (Mark Luedtke) writes: > >Question #1: >Does anyone know of a way to get at the data on the tape (probably the better >copy)? RBAK dies at some location and will not find anything further, but if >I could get it to start looking further down, I should be able to access the >data. An index, using RBAK, will pass the bad spot, but reading won't and >using '-f cur' tells me that the current location is unknown. Can I use RWMT >in raw mode to build a file then RBAK from that file? Any options at all >for the tape? > Welcome to the unreal world of the small machines! On all mainframe systems there is a way to read tape ignoring (but flagging) errors, or to read past partity errors, or some such thing. As far as I know and have seen there is nothing like that available with RBAK (or tar) This is very serious! As you found out, you cant rely on your backups being readible! Apollo really needs to address this problem with some sort of fail-safe options on rbak or tar. I suspect some of the high-powered users might have written their own polish-off-the-tape-and-read programs of their own to replace rbak. Anyone know of any??? -- /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 Sat Sep 9 04:51:02 1989 Date: 8 Sep 89 19:46:02 GMT From: bgo%pbhya%pacbell.uucp@ames.arc.nasa.gov (Bud Odekirk) Organization: Pacific * Bell, San Ramon, CA Subject: sendmail question Message-Id: <29730@pbhya.PacBell.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We are trying to get sendmail working on our network and are having all kinds of problems. The following is from the Apollo manual on sendmail: The system aliases are held in three files. The file "/usr/lib/aliases" is the master copy. A sample is given in "lib/aliases" which includes some aliases --------------------------- which must be defined. ------------------------ We don't have the file lib/aliases and the book doesn't explain what aliases must be defined. We have created our /usr/lib/aliases file and we can send to people on other systems but not our own. I appreciate any help Thanks Bud Odekirk From apollo-request@umix.cc.umich.edu Sat Sep 9 07:15:24 1989 Date: 7 Sep 89 22:39:38 GMT From: grant%steven%ole%sumax.uucp@beaver.cs.washington.edu (grant) Organization: Sierra Geophysics Inc., Kirkland, Wa. Subject: SR10.0 SYSV tape handling Message-Id: <87@steven.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I'm having some problems handling tapes from c under the SR10.0 SYSV env. First, is there any reasonable substitute for . There doesn't seem to be one. I hacked up a solution including the BSD4.3 mtio.h and a subset of the BSD4.3 ioclt.h to make it work. Some of the tape operations work others don't (such as MTWEOF). Any ideas! Compiling in BSD is not an option for me. HELP! -- Grant Peterson Sierra Geophysics, Inc . Voice: (206) 822-5200 uucp: ..!uw-beaver!sumax!quick!ole!steven!grant From apollo-request@umix.cc.umich.edu Sat Sep 9 07:21:14 1989 Date: 9 Sep 89 03:44:49 GMT From: weiner%novavax%uflorida%indri%uakari.primate.wisc.edu%csd4.csd.uwm.edu%gem.mps.ohio-state.edu. (Bob Weiner) Organization: Nova University, Fort Lauderdale, FL Subject: Re: Questions about knowledge broker Message-Id: <1461@novavax.UUCP> References: <1989Aug29.161420.2016@quintro.uucp>, <1457@novavax.UUCP>, <457f0213.205d9@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu > We are currently looking at getting knowledge broker and would like > comments from people who are using it. I am the product team leader for Knowledge Broker, and am happy to have an opportunity to respond to your questions. I'm giving you the perspective of the product developers, of course. Please feel free to contact me directly if you need more information. You said so little about KB in your reply? What interesting hypertext capabilities does it have? Can one dynamically create links while viewing documents? How does it compare to other hypertext environments? Does it provide live or hot links (yes, I know data is stored 'in place', but the KB still might need to recompute some data in order to display in a view that meets the user's need)? What is the cost? Is it DM-based or will you make it portable to encourage widespread use? > I mostly interested in > > 1. How is the speed of the product? Speed depends entirely on your site configuration. Here you provided a bunch of 'ifs' and 'buts' yet no data. Compare its retrieval and link following capabilities to other packages. Choose a platform that you feel is available to many people (a DN10000 does not qualify here)? > 4. Is it easy/hard to add your own information? Apollo also sells the (optional) Knowledge Broker Publisher's Toolkit, which allows you to add your own documents that have been produced in one of three formats: Interleaf TPS, troff, or ascii. This doesn't answer the question? How simple/impossible is it to add a link to a TPS microdocument or a graphic frame? key design feature of Knowledge Broker is its ability to handle native output from a variety of publishing systems rather than forcing you to choose or convert to a single one. We are having discussions with additional publishing software vendors to encourage their adoption of this approach. Which ones are of most interest to you? If you read your own marketing information about the KB, 6 months ago marketing made it sound as if documents of virtually any data format are 'easily' linked in to a KB database. Go out into the world and find out how people produce documents and then get cracking. Try Scribe, TeX, MS Word, FrameMaker, the Publisher, Context, etc. > 5. Can ASCII terminals use it? Not today, although we have talked about adding such support. The architecture will allow such an extension, but it hasn't been a high priority for us. Should it be? Yes, in engineering environments terminals are often hooked up to workstations. Those using terminals have no less need to access information. Joe Jaynes jtj@apollo.hp.com Apollo Computer Inc. Chelmsford, MA Thanks for taking the time to help inform the world in a customer-oriented (HP way). -- Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner (407) 738-2087 From apollo-request@umix.cc.umich.edu Sat Sep 9 13:57:04 1989 Date: 9 Sep 89 13:47:12 GMT From: jnp%mjolner%santra%tut%sunic%mcsun.uucp@uunet.uu.net (J|rgen N|rgaard) Organization: Nokia Telecommunications Oy, Espoo, Finland Subject: NFS and cc Message-Id: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hello, For the time being we are doing a larger software project distributed on a number of people each having a workstation. The source-code is managed by sccs. And all the workstations are running NFS. But trying to make an Apollo 3500/SR10.1 (BSD4.3)/NFS 2.0 (both patched from the patch tape) fit in this environment appears to be difficult. Problems are both cc and sccs, but for now only the cc is considered "cc -c main.c" gives the error: ?(cc) "main.o" - branch is not a directory (OS/naming server) which does not give me any clues to what is wrong. Any one else with the same problem ? Any hints ? Any ideas will be appreciated. -- -- | Regards, J|rgen N|rgaard ('|' is '\o{}' in \LaTeX{}) | | e-mail: jnp@tele.nokia.fi or pedersen%tnclus.dnet@tele.nokia.fi | -- telephone: <..>-358-0-511-5671 -- -- -- -- | Regards, J|rgen N|rgaard ('|' is '\o{}' in \LaTeX{}) | | e-mail: jnp@tele.nokia.fi or pedersen%tnclus.dnet@tele.nokia.fi | -- telephone: <..>-358-0-511-5671 -- From apollo-request@umix.cc.umich.edu Sun Sep 10 05:24:52 1989 Date: 9 Sep 89 17:10:23 GMT From: reb%quintro%tiamat.uucp@uunet.uu.net (Roger E. Benz) Organization: none Subject: Re: Any DSEE users out there? Message-Id: <1989Sep9.171023.26488@quintro.uucp> References: <2260001@hpcuhc.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <2260001@hpcuhc.HP.COM> edwardm@hpcuhc.HP.COM (Edward McClanahan) writes: >Anybody out there in Apollo User Land have experience with DSEE? Forgive me >if this has been discussed "ad nasueum" in this notesgroup before... We have been using DSEE for about 3 years now and generaly like it. It has a few problems but many nice features. If you (or anyone) has any questions please feel free to contact me. -- 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 Sun Sep 10 17:18:46 1989 Date: 10 Sep 89 17:40:38 GMT From: brock%tuvie%mcsun.uucp@uunet.uu.net (Inst.f.Prakt.Info 1802) Organization: Technical University of Vienna, EDP-Center Subject: Re: Deteriorating Media Message-Id: <729@tuvie> References: <1082@neptune.AMD.COM>, <13518@well.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <13518@well.UUCP> rchrd@well.UUCP (Richard Friedman) writes: >In article <1082@neptune.AMD.COM> markl@neptune.AMD.COM (Mark Luedtke) writes: >>Question #1: >>Does anyone know of a way to get at the data on the tape (probably the better >>copy)? RBAK dies at some location and will not find anything further, but if >>I could get it to start looking further down, I should be able to access the >>data. An index, using RBAK, will pass the bad spot, but reading won't and >>using '-f cur' tells me that the current location is unknown. Can I use RWMT >>in raw mode to build a file then RBAK from that file? Any options at all >>for the tape? /systest/ssr_util/cptape should help Ulrich From apollo-request@umix.cc.umich.edu Mon Sep 11 19:19:50 1989 Date: 11 Sep 89 20:48:14 GMT From: kerr%tron%umbc3%haven.uucp@purdue.edu (Dave Kerr) Organization: Westinghouse Electric. Subject: Looking for inprot templates... Message-Id: <440@tron.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi, We just received some nodes from a third party. They came in with "open" protections. Of course we want closed. According to the RAI manual, (p 6-11), you should not use install++ in update mode to reverse the protections, rather you should use inprot edacl, or chacl to change them or alternatively *INVOL* and start over. These nodes already have the third party S/W installed so we really don't want to invol and reload everything from scratch. So question is: Has anybody generated inprot templates that represent the "closed" apollo system? I'd like to get all three environments but I'll galdly accept anything. I would think that these would be of interest to others so it might be a good idea to post instead of E-mail. Thanks in advance, Dave -- Dave Kerr (301) 765-4453 kerr%tron.UUCP@umbc3.UMBC.EDU from an Internet site kerr@tron.UUCP from a smart uucp mailer {well-connected-site}!netsys!tron!kerr from a dumb uucp mailer From apollo-request@umix.cc.umich.edu Mon Sep 11 19:29:29 1989 Date: 11 Sep 89 20:54:11 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: EMACs for SR10+ Release, Where? Message-Id: <1865@dover.sps.mot.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I know this has been asked before, but I've lost the reference. I am looking for a version of EMACs for Apollos on release 10.1 or later. I'm lazy and would prefer not to have to tailor a generic version it at all possible. Thanks, 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 Tue Sep 12 13:25:36 1989 Date: 12 Sep 89 14:18:15 GMT From: larss%draken%kth%sunic%luth%eru.uucp@bloom-beacon.mit.edu (Lars Schylberg) Organization: Royal Institute Of Technology, Stockholm, Sweden Subject: Basic compiler Message-Id: <1626@draken.nada.kth.se> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I'm posting this for another person that don't have access to the net. But you could could reply either to this group or direct to me. Do someone now about a Basic compiler running on Apollo, possible something that looks like Quick Basic on PC. Lars Schylberg Email: larss@fmi.kth.se (Internet) Department of Photogrammetry larss@sekth.bitnet (Bitnet) Royal Institute of Technolgy Tel. +46 8 790 86 33 (office) S-100 44 STOCKHOLM, SWEDEN Fax. +46 8 10 91 99 -- Lars Schylberg Email: larss@fmi.kth.se (Internet) Department of Photogrammetry larss@sekth.bitnet (Bitnet) Royal Institute of Technolgy Tel. +46 8 790 86 33 (office) S-100 44 STOCKHOLM, SWEDEN Fax. +46 8 10 91 99 From apollo-request@umix.cc.umich.edu Tue Sep 12 15:26:01 1989 Date: 12 Sep 89 17:57:30 GMT From: hans%euteal%eutrc3%hp4nl%mcsun.uucp@uunet.uu.net (Hans Fleurkens) Organization: Eindhoven University of Technology, Eindhoven, The Netherlands Subject: problem with DN3000 Message-Id: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu i've encountered the following problem: i'm unable to type a caret in the input pad of an Apollo DM window. Shutting my machine doesn't seem to solve this problem. Most of time i'm using the Apollo X Server (R2) and gnuemacs, which could be a source of this problem. Does anyone know an answer to this problem? thanks, Hans Fleurkens Eindhoven University of Technology Department of Electrical Engineering Email: hans@es.ele.tue.nl From apollo-request@umix.cc.umich.edu Tue Sep 12 21:21:16 1989 Date: 12 Sep 89 19:46:00 GMT From: brian%apollo%hp-sdd%ncr-sd%ncrlnk.uucp@uunet.uu.net (Brian Holt) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: Basic compiler Message-Id: <45995c63.18e92@apollo.HP.COM> References: <1626@draken.nada.kth.se> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1626@draken.nada.kth.se> larss@nada.kth.se (Lars Schylberg) writes: >Do someone now about a Basic compiler running on Apollo, possible something >that looks like Quick Basic on PC. I remember someone posting a Basic interpreter to comp.sources a couple of years ago. It just compiled and ran (called Phil's Basic). I don't know if Phil ever did a compiler, but he had intended to. Check the comp.sources.unix archives. =brian -- Internet: brian@apollo.hp.com UUCP: {decvax,mit-eddie,umix}!apollo!brian From apollo-request@umix.cc.umich.edu Wed Sep 13 00:00:19 1989 Date: 13 Sep 89 02:00:38 GMT From: petrost%prism.cs.orst.edu.uucp@cs.orst.edu (Tony Petrossian) Organization: Oregon State Univ. -- Computer Science Subject: Deteriorating Media Message-Id: <12479@orstcs.CS.ORST.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu While you are on the subject (backups): I was told today, that I need to start backing up the apollos for EE department. I have never used an apollo and dont know much about them but I have been told that dump and rdump are not supported. Is there a way to do remote backups to a remote tape drive? I really dont want to use tar and pipes, and since I dont have an account yet I could not RTFM about other alternatives. I will appreciate any helpful hints. ------------------------------------------------------------------------------- InterNet: petrost@CS.ORST.EDU Tony Petrossian UUCP: hp-pcd!orstcs!petrost Computer Science Oregon State Univ. Corvallis OR. 97331 ------------------------------------------------------------------------------- From apollo-request@umix.cc.umich.edu Wed Sep 13 11:20:18 1989 Date: 13 Sep 89 14:05:11 GMT From: rich@eddie.mit.edu (Richard Caloggero) Organization: MIT EE/CS Computer Facility, Cambridge, MA Subject: Nedd a postscript to impress translator Message-Id: <12683@eddie.MIT.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu When we went shopping for a laser printer awhile back, we seem to have overlooked the fact that Postscript is rapidly becoming a standard. Our printer-to-be (haven't got it yet) is an Imagen station 2; it uses Impress. Can anyone provide us with either the name of a product which does this, or perhaps a public domain source which accomplishes this task. We run Apollo's SR10.1 on a Apollo DN3500 workstation. Thanx in advance. :-) -- -- 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 Wed Sep 13 19:23:29 1989 Date: 13 Sep 89 15:58:41 GMT From: andrewn%syma%icdoc%ukc%mcsun.uucp@uunet.uu.net (Andrew D Nimmo) Organization: University of Sussex Subject: routed version Message-Id: <1363@syma.sussex.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu What version of routed does SR10.1 use? -- 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 Sep 14 01:20:20 1989 Date: 14 Sep 89 02:47:34 GMT From: rchrd%well.uucp@apple.com (Richard Friedman) Organization: RCHRD 2855 Telegraph #415 Berkeley CA 94705 Subject: Re: problem with DN3000 Message-Id: <13595@well.UUCP> References: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article hans@euteal (Hans Fleurkens) writes: > >i've encountered the following problem: >i'm unable to type a caret in the input pad of an Apollo DM window. Sometimes characters drop off the keyboard. Try shaking or banging the keyboard. I regularly have problems with the letter r. Shaking the keyboard in the air a few times tends to fix it. That is, assuming it isnt a software problem thats gobbling up carets. -- /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 Sep 14 05:21:32 1989 Date: 14 Sep 89 04:54:06 GMT From: beech%plus5.uucp@uunet.uu.net (David Beecher) Organization: Plus Five Computer Services, St. Louis Subject: Apollo DN10000 Manual set FOR SALE Message-Id: <3163@plus5.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Nearly complete set of DN10000 manuals for sale. Very low mileage. We also have an additional set of user documentation (i.e. not the hardware ref manuals, etc.). The original cost of this documentation was ~$1700, we can do the deal for $1000 or best offer. We will pay the shipping (UPS Ground). I REALLY WANT TO SELL THIS. PLEASE DON'T HESITATE IF YOU ARE INTERESTED. I can be contacted by email at beech@plus5.com or by US mail at: Dave Beecher Washington University Division of Radiation Sciences 510 S. Kingshighway St. Louis, MO 63110 (314) 362-8459 For a quick response, please phone or write as I don't log in to this account very often. I also don't read this newsgroup. Feel free to leave a message on the answering machine if I am not in. From apollo-request@umix.cc.umich.edu Thu Sep 14 19:19:59 1989 Message-Id: <8909142117.AA23543@umix.cc.umich.edu> Date: 14 Sep 89 16:06:00 CST From: "DAVE ERSTAD" Subject: ios_$f1 To: "apollo" Which of the standard Apollo type managers supports records of type ios_$f1? (fixed length w/no count field). I tried rec and hdru, but they apparently don't (or maybe I'm doing something else wrong). I ideally need an answer for both 9.7 and 10.1, but will settle for the latter. BTW, where is info of this sort documented? I looked everywhere I could think of with no success. Dave Erstad DERSTAD@cim-vax.honeywell.com Principal Design Automation Engineer Honeywell SSEC From apollo-request@umix.cc.umich.edu Thu Sep 14 19:27:22 1989 Date: 14 Sep 89 21:40:00 GMT From: conliffe%caen.engin.umich.edu%mailrus%wuarchive%gem.mps.ohio-state.edu.uucp@tut.cis.ohio-state. (Darryl C. Conliffe) Organization: U of M Engineering, Ann Arbor, Mich. Subject: Opinions from New Orleans Message-Id: <45a3d0fc.14df5@ulsoy.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Ok, folks, for all of us who could not make the User Group meeting, could those of you who did share their observations? Topics? 1. Directions as the Apollo division of HP 2. Support for existing software and hardware 3. Was it worth the expense? 4. Are you going to the next one? 5. ... -- ___________________ Darryl C. Conliffe conliffe@caen.engin.umich.edu (313) 721-6069 ------------------- From apollo-request@umix.cc.umich.edu Thu Sep 14 23:17:44 1989 Date: 15 Sep 89 00:22:33 GMT From: naugle%dover%oakhill%cs.utexas.edu%mailrus.uucp@tut.cis.ohio-state.edu (Ray Naugle) Organization: Motorola SPS, Mesa, AZ Subject: SR10.1 / TCP / UUCP Message-Id: <1866@dover.sps.mot.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.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) Any help would be greatly appreciated. Thanks Ray Naugle From apollo-request@umix.cc.umich.edu Thu Sep 14 23:20:45 1989 Date: 14 Sep 89 18:21:04 GMT From: cmorgan%mntgfx%sequent%tektronix%zephyr.ens.tek.com.uucp@uunet.uu.net (Clark Morgan @ APD x4813) Organization: engr Subject: Have you ever seen "somewhere" inserted in an address? Message-Id: <1989Sep14.182104.15144@mentor.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hello. We're running HoneyDanBer UUCP in a BSD environment on Apollo HW (SR10.1). We have three external company-related sites that send us e-mail via UUCP. These sites often send us mail that arrives with a From: header that looks like so: From: .mentor.com!somewhere! Needless to say, replying to this mail does not work so well. Has anybody out there seen this problem before and do you know what's causing it? I have run the following programs through /usr/ucb/strings: sendmail uuxqt uucico smail rmail uux The only program that proved interesting was rmail: [11 ~] /usr/ucb/strings /bin/rmail @(#)rmail.c 3.1 - 87/07/15 Usage: rmail user ... /dev/null From >From %s %s remote from somewhere <---- remote from remote from %s %s -ee -f%s -i /usr/lib/sendmail pclose: status 0%o I am aware that incoming mail is handled via this flow of control: uuxqt -> rmail -> sendmail -> local_delivery_agent Is it possible that "rmail" is adding "somewhere" to these addresses? If so, why? Help... -- Clark O. Morgan -- Mentor Graphics Corp. cmorgan@mntgfx.mentor.com {backbone}!tektronix!sequent!mntgfx!cmorgan From apollo-request@umix.cc.umich.edu Fri Sep 15 07:18:27 1989 Message-Id: <8909150933.AA14155@umix.cc.umich.edu> Date: Fri, 15 Sep 89 11:07:16 MEZ From: Walter Muellner Subject: again:BiBTeX To: apollo@umix.cc.umich.edu This is (I think) my last request, then I will give up and invent the wheel again. Does anybody out there have a running BiBTeX for APOLLOs. I can't get a copy of it from these 'ftp'-sites, because I'm working in EARN (BITNET). I have the version from the TeX82 UNIX-distribution, but it is impossible to compile on the APOLLO (we don't have a Pascal under UNIX which compiles this BiBTeX). So I would appreciate a copy of C-version if somebody has one. Thanks to any hints. Walter. ------------------------------------------------------------------------ Walter Muellner ! /X /X Institut of Statistics and !  // // / Computer Science ! X/ o X/ o X University of Vienna, Austria ! // /~~ /  Lenaugasse 2/8 ! / ==/ A-1080 Wien ! e-mail: A4424DAA@AWIUNI11.BITNET ! ------------------------------------------------------------------------ From apollo-request@umix.cc.umich.edu Fri Sep 15 11:24:43 1989 Message-Id: <8909151401.AA04534@umix.cc.umich.edu> Date: 15 Sep 89 08:52:00 CST From: "DAVE ERSTAD" Subject: IOS Problem (long) To: "apollo" Here's a hopefully basic IOS question someone can address. I'm creating a REC type file with 4 byte records. Prior to closing the file, I can check and verify that the records are 4 bytes. When I reopen the file, the records are 44 bytes. I assume I'm doing something trivially wrong. A sample program and its output are shown below. The file is being created correctly. A DMPF of the file shows the length field as 8 (includes the 4 byte count field), and I can access the file as a Pascal FILE OF INTEGER32, for example. The data retrieved by an ios_$locate appears to have no bearning on the data actually in the file. ---------PROGRAM------------------------------------------- #include "/sys/ins/base.ins.c" #include "/sys/ins/ios.ins.c" #include "/sys/ins/error.ins.c" #include "/sys/ins/type_uids.ins.c" void check_status(status) status_$t status; { if (status.all != status_$ok) { error_$print(status); } } main() { ios_$id_t file0; status_$t status; char name[255]; short name_len; long four = 4; long current_time = 12345; char *read_buf; /* Create record structured file */ strcpy(name, "/user_temp/file0"); name_len = strlen(name); ios_$create(name, name_len, records_$uid, ios_$recreate_mode, ios_$write_opt, file0, status); check_status(status); /* Make fixed length records, 4 bytes per record */ ios_$set_rec_type(file0, ios_$f2, four, status); check_status(status); /* Stick in five records */ ios_$put(file0, ios_$no_put_get_opts, current_time, four, status); check_status(status); ios_$put(file0, ios_$no_put_get_opts, current_time, four, status); check_status(status); ios_$put(file0, ios_$no_put_get_opts, current_time, four, status); check_status(status); ios_$put(file0, ios_$no_put_get_opts, current_time, four, status); check_status(status); ios_$put(file0, ios_$no_put_get_opts, current_time, four, status); check_status(status); /* Seek back */ ios_$seek(file0, ios_$absolute, ios_$rec_seek, (long)1, status); check_status(status); /* Check length */ printf("next length from ios_inq_cur_rec_len is %d\n", ios_$inq_cur_rec_len(file0, status)); check_status(status); /* Clost file */ ios_$close(file0, status); check_status(status); /* Reopen, again seek to same location, and check length */ file0 = ios_$open("/user_temp/file0", strlen("/user_temp/file0"), ios_$no_open_options, status); check_status(status); ios_$seek(file0, ios_$absolute, ios_$rec_seek, (long)1, status); check_status(status); printf("next length from ios_inq_cur_rec_len is %d\n", ios_$inq_cur_rec_len(file0, status)); check_status(status); printf("next length from ios_$locate is %d\n", ios_$locate(file0, ios_$no_put_get_opts, read_buf, (long) 200, status)); check_status(status); } ---------OUTPUT------------------------------------------- $ cc demo No errors, no warnings, C Compiler, Rev 5.50 $ demo.bin next length from ios_inq_cur_rec_len is 4 next length from ios_inq_cur_rec_len is 44 next length from ios_$locate is 44 ----------------------------------------------------------- Dave Erstad Principal Design Automation Engineer Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Fri Sep 15 13:23:39 1989 Date: 15 Sep 89 14:45:30 GMT From: leonard%h.cs.wvu.wvnet.edu%haven%aplcen%ginosko%usc.uucp@ucsd.edu (Jon B Leonard) Organization: West Virginia University, Morgantown,WV Subject: New Apollo Workstation? Message-Id: <446@h.cs.wvu.wvnet.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Is there a new apollo workstation that was just released? I am a grad student who is interested in getting a cheap unix workstation, and the blurb in our local newspaper said that the price was about $3700. Is this price right? What do you get for the money? Thanks in advance From apollo-request@umix.cc.umich.edu Fri Sep 15 13:28:57 1989 Date: 15 Sep 89 13:29:00 GMT From: mishkin%apollo.uucp@eddie.mit.edu (Nathaniel Mishkin) Organization: Apollo Computer, Chelmsford, MA Subject: Re: ios_$f1 Message-Id: <45a71ed4.1d6d5@apollo.HP.COM> References: <8909142117.AA23543@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8909142117.AA23543@umix.cc.umich.edu> derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") writes: >Which of the standard Apollo type managers supports records of type >ios_$f1? (fixed length w/no count field). I tried rec and hdru, >but they apparently don't (or maybe I'm doing something else wrong). I'm afraid F1-style records are an abstraction still in search of an implementation. None of the standard Apollo-supplied file types support F1 records. -- -- Nat Mishkin Apollo Computer Inc., Chelmsford, MA mishkin@apollo.com From apollo-request@umix.cc.umich.edu Fri Sep 15 15:25:25 1989 Date: 15 Sep 89 16:57:15 GMT From: kerr%tron%umbc3%haven.uucp@ames.arc.nasa.gov (Dave Kerr) Organization: Westinghouse Electric Corporation Subject: Need help with getty under SR10.1 Message-Id: <442@tron.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi, I'm having some problems with /etc/getty on SR10.1.0.5 and was hoping someone out there could help me out. Problem 1: When I first brought getty up on the serial port, it failed to recognize the erase character. For example when I'd type: $ ls^H^H (meaning ls backspace backspace return) I'd get an error: : Not found. Operating at a slower baudrate revealed that after pressing return, the full command including the backspaces would be echoed to the screen followed by the error message. This seemed to indicate that the backspaces simply weren't being recognized as being erase characters. Yet stty showed the erase character to be set properly. This problem existed in both the sys5 and bsd environments. I eventually tried using the tctl -default command as: $ tctl -default -speed 2400 -cvt_nl -bpc 7 -parity even Which fixed the problem. I assumed that some tctl setting was wrong, and that the -default option cleared it up. I compared the tctl settings from one of the "bad" sessions to that of a good session, then issued tctl commands to make the tctl settings match that of the bad session. When I did this the erase characters all worked just fine. So what was the real problem? Problem 2: A few hours after things seemed to be working OK, I tried to call in. The modem connected but then immediately hung up. I tried again with the same results. I did a kill -1 1 from the node's keyboard and the problem went away, but problem #1 was back (no erase character), the tctl -default command fixed the problem. Problem 3: Really question 3 :-), Is there a ungetty command or something similar that allows a modem to be shared for incoming and outgoing calls? ********************************************* Details of my configuration: OS: SR10.1.0.5 All three environments installed, currently bsd is the default. Hardware: DN3000, 4MB ********************************************* Modem: Hayes 2400 Baud Smartmodem. Modem Setup: First I would turn off getty by editing the /etc/ttys file then kill -1 1. Then using emt I'd connect to the port and issue: AT&F&W Restore factory settings and save ATS0=1&D2E0Q1&C1&W Meaning: Auto answer on 1 ring, Recognize DTR, Disable Command echo, Disable result codes and recognize DCD. ********************************************* The /etc/ttys entry looks like: tty01 "/etc/getty D2400" dialup on # Hayes 2400 baud modem ********************************************* The /etc/gettytab entry for this is: # 9/15/89 D. Kerr. Default modified added :to:, changed sp to 2400, made # even parity. default:\ :ep:fd#1000:im=\r\n\r\nDomain/OS sr10 (%h) (%t)\r\n\r\r\n\r:sp#2400: \ :to#30: # # Fixed speed entries c|std.300|300-baud:\ :nd#1:cd#1:sp#300: f|std.1200|1200-baud:\ :fd#1:sp#1200: 6|std.2400|2400-baud:\ :sp#2400:ht: # # Fast dialup terminals, 2400/1200/300 rotary (can start either way) # D2400|Fast-Dial-2400:\ :nx=D1200:tc=2400-baud: 3|D1200|Fast-Dial-1200:\ :nx=D300:tc=1200-baud: 5|D300|Fast-Dial-300:\ :nx=D2400:tc=300-baud: -- Dave Kerr (301) 765-4453 kerr%tron.UUCP@umbc3.UMBC.EDU from an Internet site kerr@tron.UUCP from a smart uucp mailer {well-connected-site}!netsys!tron!kerr from a dumb uucp mailer From apollo-request@umix.cc.umich.edu Fri Sep 15 17:18:55 1989 Date: Fri, 15 Sep 89 15:03:38 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8909151903.AA08561@richter.mit.edu> To: apollo@umix.cc.umich.edu, leonard%h.cs.wvu.wvnet.edu%haven%aplcen%ginosko%usc.uucp@ucsd.edu Subject: Re: New Apollo Workstation? Apollo annouced the DN2500 workstation at the ADUS conference. For $3990 you get: 20 Mhz 68030/68882 4MB of RAM, expandable to 16 MB Your choice of Domain token ring, ethernet, or IBM token ring network controller 15 inch monochrome screen SCSI controller (built into motherboard) Options: 19 monochrome screen (1280x1024) [no color screens supported] 1 or 2 internal SCSI disks, 100 or 200 MB each additional external disks, 8mm tape, and 1/4 inch tape If you are at an educational institution, HP is offering a 38% discount (on both HP and Apollo H/W), so the price of a diskless monochrome system will run you about $2500 (which is less than MIT's discounted price for a Macintosh SE with 2 floppies and 4MB of memory and an ethernet card [which would run about $3500]). -- 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 Sep 15 19:15:55 1989 Date: 15 Sep 89 21:42:48 GMT From: david@g.ms.uky.edu (David Herron -- One of the vertebrae) Organization: U of Kentucky, Mathematical Sciences Subject: Re: Have you ever seen "somewhere" inserted in an address? Message-Id: <12691@s.ms.uky.edu> References: <1989Sep14.182104.15144@mentor.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu MMDF's rmail uses "remote from somewhere" when it can't figure out where the mail came from. (No From_ or >From_ lines). -- <- David Herron; an MMDF guy <- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <- <- A job in the hand is worth two in the bush ... From apollo-request@umix.cc.umich.edu Fri Sep 15 21:17:26 1989 Date: 15 Sep 89 14:23:16 GMT From: kent%sas%rti.uucp@mcnc.org (Paul Kent) Organization: SAS Institute Inc, Cary NC Subject: apollo ftp and $HOME/.netrc Message-Id: <1228@sas.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu g'day i have asked the local sys-admin but no lucke there... is the .netrc mechanism on sr9.7 broken? /com/ftp appears to ignore the file, /bsd4.2/usr/ucb/ftp spews /udr/saspmk/.netrc: Invalid argument my .netrc reads like this. machine manzi login kent password fred /com/bldt tells me i have aegis/domain-ix kernelm, rev 9.7.3.2 much obliged, paul. -- ---- nothing ventured, nothing disclaimed ---- paul kent, SAS Institute, box 8000, cary nc 27512-8000 -- 919 467 8000 .... {seismo|mcnc}!rti!sas!kent From apollo-request@umix.cc.umich.edu Fri Sep 15 23:18:19 1989 Date: 14 Sep 89 14:46:00 GMT From: wvanbeek%tippy%pur-phy.uucp@ee.ecn.purdue.edu Subject: Transfer help and a sale(?) Message-Id: <25800002@tippy> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am just at the tail end of using the DN3000 and need some help in reading a tape and transferring the files (ASCII) back to me. We are discontuing the use of machine. So the question. Would someone be willing to read a tape from our 3000 and E-Mail the text files back to me? The second question. Would anyone be interested in a DN3000. I can make a very realistic deal. E-Mail responses to WVANBEEK@MIDAS.MGMT.PURDUE.EDU would be appreciated. I will monitor this group for a period of time to get some of the non E-MAIL responses. Thanks folks. ...bill wvanbeek@midas.mgmt.purdue.edu tippy!wvanbeek@newton.physics.purdue.edu (317) 494-4526 Asst. Director, Krannert COmputer Center Krannert School of Management Purdue University, West Lafayette, IN From apollo-request@umix.cc.umich.edu Sat Sep 16 19:24:46 1989 Date: 16 Sep 89 21:00:56 GMT From: gdau100%bguvm.bitnet%barilvm%psuvm.uucp@psuvax1.cs.psu.edu (Jonathan B. Owen) Organization: Ben-Gurion University, Computation Center, Israel Subject: SYS-V msgget and msgput services under DOMAIN OS Message-Id: <612GDAU100@BGUVM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am developing a system on an Apollo 4500 using SR10.2. The code is written in Verdix Ada. The body of our IPC package uses SYS-V msgget and msgput services. We have a need to wait on a mailbox with a timeout period. At first, I created a task to wait on the mailbox, upon invokation of the IPC.Read service. If the task did not receive a message within the timeout period, I would raise an exception from the main thread of the procedure. This of course did not work, since by the definition of Ada, the procedure will not terminate until all tasks within are completed or able to terminate. In order to solve this problem, I thought I might send a message to the mailbox from the main thread, after the timeout period. This would enable the task to terminate, instead of being stuck on the msgget service. It seems that it is not a good idea to call msgget and msgput from the same process. As far as i could tell, attempting so hangs the process! To solve this problem, it seems I might have to create a simple process, which will receive a request to send a message to a certain mailbox, in a ping-pong fasion. This probably will solve the problem... I am not the one who implemented the interface from Ada to the above services so I am not familure with the msgget and msgput services. Do they support a timeout in some way? If not, do you know of a better way to implement a msgget with a timeout period? Any help is welcome... Jonathan ______________________________________________________________________________ (--) /--) /-(\ Email: gdau100@bguvm (bitnet) \ / /--K | \|/\ /\/) /|-\ Snail: 55 Hovevei Zion _/_/o /L__)_/o \/\__/ \X/ \_/ | |_/ Tel-Aviv, 63346 ISRAEL (/ Jonathan B. Owen Voice: (03) 281-422 Point of view: A chicken is the means by which an egg reproduces an egg. ______________________________________________________________________________ From apollo-request@umix.cc.umich.edu Sat Sep 16 19:27:55 1989 Date: 15 Sep 89 18:50:38 GMT From: huggins%ti-csl%pollux%texsun%sun-barr.uucp@apple.com (Gray Huggins) Organization: TI PAC, Dallas Subject: Help building GNU Emacs on Apollo Message-Id: <91308@ti-csl.csc.ti.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I need assistance in bringing up Emacs on my Apollo. I'm running bsd4.3 on SR10.1. I have the 18.55 version of Emacs. I'm using m-apollo.h and s-bsd4-3.h in the config.h with no modifications. I've altered src/Makefile line for CPP. After make all and make install, emacs dies with a memory fault error. Any pointers would be appreciated.. Thanks. From apollo-request@umix.cc.umich.edu Sun Sep 17 19:17:18 1989 Date: 17 Sep 89 21:07:55 GMT From: ken@gatech.edu (Ken Seefried III) Organization: North Avenue Trade School Subject: New low-ball workstation from HP/Apollo? Message-Id: <19208@gatech.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu --- Not sure which is the most appropriate group... The Wall Street Journal the other day had an article about a new workstation from the Apollo subsidiary of HP (or some such terminology) to be announced this week. Not that big a deal these days, save the fact that the slated price is under $4,000 list. The article went on to talk about how this box was going to shake up the price structure of the industry, with other hardware houses slashing prices to compete. The article specificly mentioned the Sun 3/80, as I remember. Sooooo...the inevitable question is: what does my $4,000 get me? Equally important: How much more than $4K does it take to make a useable system? Other nice things to know are academic discounts and such, but first things first. ...ken seefried iii ...!!gatech!ken ken@gatech.edu Programmes are the magic spells cast over computers that allow them to turn ones input into error messages... From apollo-request@umix.cc.umich.edu Sun Sep 17 23:14:28 1989 Date: 15 Sep 89 16:48:23 GMT From: nmeth%prlhp1%idec%stc%ukc%mcsun.uucp@uunet.uu.net (nmeth) Organization: Philips Research Laboratories, Redhill, UK Subject: Help needed to read "foreign" cartridge tapes Message-Id: <983@prlhp1.prl.philips.co.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have some antique Philips PMDS II systems running Sys3 Unix which we intend to junk, moving the applications onto Apollos under bsd4.2. There are several megabytes of current project data, plus loads of cartridges of archived prject data that we want to either move to the Apollos, or be able to access in the future if necessary. Ideally we would prefer to not have to load all this data onto the PMDS and then transfer (using Kermit?). So... 1. Has anyone information on the tape format used by the PMDS II (It is a quarter inch cartridge, but we think it predates the QIC format - needless to say, everyone who should know within Philips left the company years ago :-) ) 2. The data has been archived using dump/restore. This doesn't exist on Apollo Unix - anyone ported a copy, and where can I get sources. 3. Is it possible to read non-QIC cartridges on Apollos? 4. If non-QIC cartridges can't be read by Apollos, can Suns read them?? Any other help will be very welcome - its starting to look as though we are going to have to load all this data back on to the PMDS and push it across a serial connection (and the PMDS doesn't even have UUCP or any form of networking!!). Nigel Metheringham Philips Components Application Lab New Road, Mitcham, Surrey, UK phone: +44-1-648-3471x3528 fax: +44-1-648-4018 email: nmeth@prl.philips.co.uk From apollo-request@umix.cc.umich.edu Mon Sep 18 07:21:29 1989 Date: 18 Sep 89 06:27:59 GMT From: cees%maestro%hp4nl%mcsun.uucp@uunet.uu.net (Cees Keyer) Organization: AHA-TMF (Technical Institute), Amsterdam, The Netherlands Subject: Registry SR9.7 Message-Id: <1026@maestro.htsa.aha.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hello netlanders, I have encountered a problem with a local registry on a SR9.7 dn3000. The problem is as follows: If i use the passwd command to change a password it produces the following error " Can't close registry ". I read the manual twice but coudn't find any pointer on the cause of the problem. So if anyone outhere could give me some pointers on the problem I would be very glad. Thanks in advance, Cees Keyer btw No acid rain on my brain :-( -- 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 UUCP: {backbones}!mcvax!hp4nl!htsa!tamtam!cees. From apollo-request@umix.cc.umich.edu Mon Sep 18 11:18:34 1989 Date: 18 Sep 89 13:26:45 GMT From: dvadura%watdragon%watmath.uucp@iuvax.cs.indiana.edu (Dennis Vadura) Organization: Computer Science Dept., University of Waterloo Subject: Re: New Apollo Workstation? Message-Id: <16462@watdragon.waterloo.edu> References: <8909151903.AA08561@richter.mit.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8909151903.AA08561@richter.mit.edu> krowitz@RICHTER.MIT.EDU (David Krowitz) writes: >deleted hardware description ... > This sounds nice, but what about software? Is it going to be as expensive as the regular distribution? -dennis -- -------------------------------------------------------------------------------- The only happy people are Single MEN |Dennis UUCP,BITNET: dvadura@water and Married WOMEN. |Vadura EDU,CDN,CSNET: dvadura@waterloo ================================================================================ From lubkin@apollo.com Tue Sep 19 17:41:14 1989 Message-Id: <8909192202.AA04268@xuucp.ch.apollo.com> From: lubkin@apollo.com Date: Tue, 19 Sep 89 17:51:08 EDT Subject: INFO-DSEE MAIL To: dsee_list:@apollo.com Date: thu, 14 sep 89 17:07:57 From: conliffe@caen.engin.umich.edu (Darryl C. Conliffe) Subject: How do you ... recover the space used by D3M in a DSEE library? - Darryl ====================================================================== Post to info-dsee@apollo.com Administrative mail to info-dsee-request@apollo.com ====================================================================== ------- From lubkin@apollo.com Tue Sep 19 17:41:17 1989 Message-Id: <8909192203.AA04282@xuucp.ch.apollo.com> From: lubkin@apollo.com Date: Tue, 19 Sep 89 17:52:02 EDT Subject: INFO-DSEE MAIL To: dsee_list:@apollo.com Date: thu, 14 sep 89 10:12:17 From: conliffe@caen.engin.umich.edu (Darryl C. Conliffe) Subject: More questions on sf_helper When starting dsee here, I get (WARNING) Unable to create local Store and Forward queue "/sys/sf/local_q". - insufficient rights to queue (store and forward manager/lib) (WARNING) Without the local queue, certain DSEE operations may fail if remote objects are unavailable. What rights are required, and which routine looks at /sys/sf/local_q? - Darryl ====================================================================== Post to info-dsee@apollo.com Administrative mail to info-dsee-request@apollo.com ====================================================================== ------- From lubkin@apollo.com Tue Sep 19 17:42:37 1989 Message-Id: <8909192203.AA04275@xuucp.ch.apollo.com> From: lubkin@apollo.com Date: Tue, 19 Sep 89 17:51:36 EDT Subject: INFO-DSEE MAIL To: dsee_list:@apollo.com Date: thu, 31 aug 89 16:57:12 From: conliffe@caen.engin.umich.edu (Darryl C. Conliffe) Subject: Impact of sf_helper In a mixed network of SR9.7 and SR10.1 nodes, which version(s) of sf_helper need to be running? Does it make a difference? - Darryl ====================================================================== Post to info-dsee@apollo.com Administrative mail to info-dsee-request@apollo.com ====================================================================== ------- From lubkin@apollo.com Tue Sep 19 17:43:15 1989 Message-Id: <8909192212.AA04695@xuucp.ch.apollo.com> From: lubkin@apollo.com Date: Tue, 19 Sep 89 18:01:47 EDT Subject: INFO-DSEE mail To: dsee_list:@apollo.com From: lubkin Date: tue, 19 sep 89 17:58:17 Subject: Ada Configuration Management with DSEE The Technology Brief "Ada Configuration Management with DSEE" is available from Apollo by calling the Apollo Response Center at 1-800-2APOLLO. -- David Lubkin. ------------------------------------------------------------------- / DSEE Project \ | Apollo Computer | | A Subsidiary of Hewlett-Packard | | | \ lubkin@apollo.com / ------------------------------------------------------------------- ====================================================================== Post to info-dsee@apollo.com Administrative mail to info-dsee-request@apollo.com ====================================================================== ------- ------- From apollo-request@umix.cc.umich.edu Tue Sep 19 17:53:25 1989 Message-Id: <8909192005.AA15889@umix.cc.umich.edu> Date: 19 Sep 89 14:57:00 CST From: "DAVE ERSTAD" Subject: Re: IOS Problem (long) To: "apollo" Yes, we found the problem with the open call last night. I'm a little surprised that a 0 length file name is legal, though. The .h files, as I'm sure you are aware, aren't an option for those of us who still need to support both SR9 and SR10 systems. I expect I'll be supporting SR9 based code at least into first quarter 90. Then, I'll close my eyes and try to forget I ever knew what a std_$call was :-) Thanks for your help. It's greatly appreciated, although it's unfourtunate the hotline isn't good enough to make these kinds of questions necessary (I was originally told by the support engineer that he was "pretty sure" that a REC type file could do an ios_$f1). Of course, this ios_$open is just a dumb programming bug... I should know better. Dave Erstad Principal Design Automation Engineer Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Tue Sep 19 19:48:37 1989 Date: 19 Sep 89 22:25:08 GMT From: sahayman@iuvax.cs.indiana.edu (Steve Hayman) Organization: Computer Science Department, Indiana University Subject: rbak/wbak tape format Message-Id: <26290@iuvax.cs.indiana.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Anybody know where I can find some documentation on rbak/wbak tape format? We're dumping a variety of different machines to an Exabyte drive connected to one of our Suns, and I'd like to be able to make a list of what files are on the tape. It would be handy to decode rbak/wbak format without having to ship the contents of the tape over the network to an Apollo, just so I could get a table of contents. So, I want to write a little program (on the Sun) to look at the rbak tape on the Sun and give me a table of contents, but I can't find any documentation on rbak format. Can anyone help? Please respond by mail and I'll summarize to the net. Thanks. Steve P.S. In case anyone else is trying to do this sort of thing ("wbak -stdout / | rsh some-sun dd of=/dev/exabyte-tape-drive") you may find that the 10.1 "wbak -stdout" doesn't actually write anything to stdout. Use the 10.0 wbak, it works OK. -- Steve Hayman Workstation Manager Computer Science Department Indiana U. sahayman@iuvax.cs.indiana.edu (812) 855-6984 From apollo-request@umix.cc.umich.edu Tue Sep 19 21:39:19 1989 Date: 19 Sep 89 11:39:24 GMT From: andrewn%syma%icdoc%ukc%mcsun.uucp@uunet.uu.net (Andrew D Nimmo) Organization: University of Sussex Subject: sockets and bugs and patches.... Message-Id: <1372@syma.sussex.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In the os.v.10.1__notes file is the following, "At SR10, there is one programming interface to TCP/IP, the 4.3BSD socket interface, which now supports raw sockets. Although the socket interface is BSD functionality, it can be used in all three environments. A new manual which describes the socket interface, will be available after the SR10 release. For the present, consult the Domain Programming Tools Refernece and the BSD Programmers Reference." Has this new manual been released? Can someone from Apollo send me a list of known bugs and available patches - Apollo UK seems to be too busy at the moment. 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 Tue Sep 19 21:43:55 1989 Date: 19 Sep 89 15:34:39 GMT From: dente%els.ee.man.ac.uk%mucs%ukc%mcsun.uucp@uunet.uu.net (Colin Dente) Organization: University of Manchester, UK Subject: Need help with Laser Jet printer & prsvr Message-Id: <6501@ux.cs.man.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The boss just gave me a bright and shiny HP Laserjet IID, and told me to get on with it. So, I dug out the ADUS tape with the laserjet driver on it - to find that it consists only of the source code, and the compiled form of the same (which, incidentally, is wrong - prsvr is a pre9.5 object - so you need to use the 9.2 pascal compiler to compile the driver). Does anyone have any more information about this program? Dare I ask whether any documentation has ever existed for it? Or has anyone got a better one just for the Laserjet IID? While I'm asking questions, does anyone have a printer_config.data for it? BTW - I'd be interested in stuff for 9.7 *or* 10.1 - it doesn't really bother me which node I hang it off. One more thing - when are Apollo going to start supporting HP peripherals? - after all, they really *should* now..... Cheers 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 Wed Sep 20 11:33:52 1989 Message-Id: <8909201357.AA07132@umix.cc.umich.edu> Date: 20 Sep 89 08:42:00 CST From: "DAVE ERSTAD" Subject: Re: IOS Problem (long) To: "apollo" > Files with a 0 length name are a handy way of > having temporary working files ... you don't > have to worry about conflicts with existing > file names, and when you close the file it > just goes away. Ah, but I didn't get a file - I actually opened the directory itself, hence the size of 44 bytes (which is the size of a name_$dir_entry_t, at least at 9.7). It may be that a language open works the way you described, but ios_$open apparently doesn't. Dave Erstad Principal Design Automation Engineer Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Wed Sep 20 17:56:00 1989 Date: 20 Sep 89 07:17:05 GMT From: news%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%gryphon%hacgate%usc.uucp@apple.com (Dave Hayes) Organization: Jet Propulsion Laboratory Subject: Test Message-Id: <1989Sep20.071705.26598@elroy.jpl.nasa.gov> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I hope this works! Hello Net! From apollo-request@umix.cc.umich.edu Wed Sep 20 19:43:29 1989 Date: 20 Sep 89 17:15:53 GMT From: jdc%naucse.uucp@arizona.edu (John Campbell) Organization: Northern Arizona University, Flagstaff, AZ Subject: Apollo 'C' compiler Message-Id: <1708@naucse.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Well, we just received our first apollos on campus. I was surprised to discover that there was no 'C' compiler as part of the base distribution. Lex, yacc, etc. are all there--no 'C' compiler. So we're ignorant--but why is this "normal" component of unix missing and what do people do without it? For instance, we expect to attempt porting some fortran programs. The department owning the machine did buy a fortran compiler, but my experience on Masscomps, 3b1's and Ultrix machines leads me to believe that we'll want to write some little 'C' programs to assist in any porting projects. Not only that, but I'd like to think I could put some of the public domain software up on an apollo. Am I dumb or what? -- John Campbell ...!arizona!naucse!jdc CAMPBELL@NAUVAX.bitnet unix? Sure send me a dozen, all different colors. From apollo-request@umix.cc.umich.edu Wed Sep 20 21:27:35 1989 Message-Id: <8909191528.AA07284@umix.cc.umich.edu> Date: Tue, 19 Sep 89 11:19:05 EDT From: "Charles J. Alber" Subject: Postscript Fonts for Chinese To: apollo@umix.cc.umich.edu Does anyone know where I can find Postscript fonts for Chinese? This is my first message to the net, if indeed it reaches the net. From apollo-request@umix.cc.umich.edu Wed Sep 20 21:38:43 1989 Date: 20 Sep 89 22:04:18 GMT From: covertr%force%hrc%asuvax.uucp@handies.ucar.edu (Richard E. Covert) Organization: gte Subject: Re: EMACs for SR10+ Release, Where? Message-Id: <45c21323.14a1f@force.UUCP> References: <1865@dover.sps.mot.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1865@dover.sps.mot.com>, turner@bwana.sps.mot.com writes: > I know this has been asked before, but I've lost the reference. > I am looking for a version of EMACs for Apollos on release > 10.1 or later. > > Robert Turner (602) 994-6837 ...!uunet!dover!turner or turner@dover.sps.mot.com I would like to get a copy of EMACS or GNU Emacs for our apollos also. we are using SR9.7 and SR10.1. Can anyone help??? Richard (gtephx!covertr) Covert From apollo-request@umix.cc.umich.edu Wed Sep 20 21:49:56 1989 Date: 19 Sep 89 09:45:57 GMT From: jnp%mjolner%santra%tut%sunic%mcsun.uucp@uunet.uu.net (J|rgen N|rgaard) Organization: Nokia Telecommunications Oy, Espoo, Finland Subject: gcc, gdb, gas implementations for Apollo SR10(.1) ??? Message-Id: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hello, As far as I remember I think I saw someone mentioning that he(/she) would adapt gdb for Apollo/COFF. Is this so ? And will the person contact me ? I maybe interested in doing some of the work. -- -- -- | Regards, J|rgen N|rgaard ('|' is '\o{}' in \LaTeX{}) | | e-mail: jnp@tele.nokia.fi or pedersen%tnclus.dnet@tele.nokia.fi | -- telephone: <..>-358-0-511-5671 -- From apollo-request@umix.cc.umich.edu Wed Sep 20 22:28:57 1989 Date: 19 Sep 89 07:44:58 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: Remote dump and restore Message-Id: <699@prles2.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I have noticed that there is a man page for rmt (remote magtape protocol module) in sr10.1, but the command itself is missing. Was this a mistake made by Apollo when they ported the BSD man pages to sr10.1, or does it mean that Apollo intend to support rmt and related commands like rdump and rrestore in the near future ? 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 Wed Sep 20 23:47:03 1989 Date: 20 Sep 89 21:09:13 GMT From: rgs%cipher%ncr-sd%ncrcae%hubcap.uucp@gatech.edu (Bob Schultz) Organization: Cipher Data, San Diego Subject: SR10.1 vt100 problem Message-Id: <254@cipher.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Has anyone out there had any success running the vt100 emulator on a 10.1 node (DN3000) that has only the BSD environment installed? We repeatedly get "Cannot create vt100 window" when first trying to execute vt100, however vtserver does get started and continues to run. Once vtserver is running, further attempts to run vt100 just hang. We have not experienced the problem on our other 10.1 nodes (DN3010, DN4000) BUT they have all three environments installed. Is this a known problem or have we overlooked something? Bob Schultz - ncr-sd!cipher!rgs voice (619) 693-7054 From apollo-request@umix.cc.umich.edu Thu Sep 21 00:08:57 1989 Date: 20 Sep 89 22:20:03 GMT From: weiner%novavax%uflorida%uakari.primate.wisc.edu%uwm.edu%gem.mps.ohio-state.edu.uucp@tut.cis. (Bob Weiner) Organization: Motorola Inc. Subject: Re: New Apollo Workstation? Message-Id: <1468@novavax.UUCP> References: <8909151903.AA08561@richter.mit.edu>, <16462@watdragon.waterloo.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <16462@watdragon.waterloo.edu> dvadura@watdragon.waterloo.edu (Dennis Vadura) writes: In article <8909151903.AA08561@richter.mit.edu> krowitz@RICHTER.MIT.EDU (David Krowitz) writes: >deleted hardware description ... > This sounds nice, but what about software? Is it going to be as expensive as the regular distribution? An Apollo SE today told me that the new model DN2500 requires SR10.2 to run! SR10.2 might not ship until early next year (increased quality audits under the HP way, I understand). This means that only sales units and demo units with beta SR10.2 software will be shipping very soon. The main reason a new release is needed is that the /sau?? system specific software is different. -- Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner (407) 738-2087 From apollo-request@umix.cc.umich.edu Thu Sep 21 04:21:42 1989 Date: 20 Sep 89 23:06:02 GMT From: bgo%pbhya%pacbell%amdahl.uucp@ames.arc.nasa.gov (Bud Odekirk) Organization: Pacific * Bell, San Ramon, CA Subject: Unix mail problem Message-Id: <30030@pbhya.PacBell.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We recently converted all of our users from DPSS mail to Unix mail (mailx), we are having response problems, getting fork I/O error messages, and numerous other problems. We have about 460 users on 86 nodes. All of the Unix mail is located on one node (//s5/sys5/usr/mail). We contacted Apollo's Unix Mail expert in Chelmsford. His initial response was that unix mail (and mailx) was designed to work on a one-machine system such as a mainframe or mini. He questioned the use of it on a multi-machine system such as our token ring network. He feels the problems we are experiencing are a result of too many machines trying to perform a function designed for one machine to handle. I know that there are a lot bigger systems than ours that are using Unix mail. I would appreciate any comments, suggestions, recommendations, etc Thanks We have a very large mailx system configuration file (/usr/lib/mailx/mailx.rc) and I suspect that is the problem. /\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\ Bud Odekirk 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 Sep 21 07:37:45 1989 Date: 21 Sep 89 00:23:52 GMT From: jcz%sas%rti.uucp@mcnc.org (John Carl Zeigler) Organization: SAS Institute Inc, Cary NC Subject: Will SAS Institue support the 2500?? Message-Id: <1239@sas.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Well, after my last posting about us not supporting the 10000 and 2500, I come to find that the 2500 (which I had never heard of...) may be binary compatible with the 3500. If it is, the the Apollo version of the SAS System will run on it. Sorry to have added to net.confusion. -- --jcz John Carl Zeigler Manager, UNIX Host R&D SAS Institute Inc. Cary, NC 27512 (919) 467-8000 ...!mcnc!rti!sas!jcz From apollo-request@umix.cc.umich.edu Thu Sep 21 07:52:40 1989 Date: 21 Sep 89 04:59:39 GMT From: abair%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Alan Bair) Organization: SPS CAD, Motorola Inc., Austin, Texas. Subject: Info on Apollo Emacs Message-Id: References: <1865@dover.sps.mot.com>, <45c21323.14a1f@force.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Here is the README file from patches by Leonard Zubkoff to adopt Emacs for SR9.7 and SR10.1. These also provide support to allow Emacs to work with the DM, read the file for more details. I obtained the code from the osu-cis UUCP site. Its probably available on sites that store the GNU code. The patches are for Emacs 18.54, but I succesfully(?) have used them on a 18.52 release(too lazy to upgrade :) Alan Bair SPS CAD Austin, Texas Motorola, Inc. UUCP cs.utexas.edu!oakhill!turbinia!abair -------------------------------------------------------------------------- GNU Emacs Apollo GPR Support Leonard N. Zubkoff lnz@lucid.com Lucid, Incorporated 1 May 1989 This modified version of GNU Emacs 18.54 includes support for using the Apollo Domain Graphics Primitives (GPR) for display operations. This version of GNU Emacs only functions under Domain/OS SR10.1 or SR9.7 on 680x0 machines and SR10.1 on PRISM machines; it also includes various bug fixes for the Apollo that are not in the GNU Emacs standard distribution. The included executable files are compound executables built for Domain/OS SR10.1 on 68020/68030 and PRISM machines. If you received source only, or if the included executables are not suitable for your needs, here are instructions for rebuilding GNU Emacs: To produce 68020/68030 and On a 68020/68030 node running SR10.1, type PRISM compound executables "build-apollo-emacs". After it completes, move to a PRISM node running SR10.1 and type "build-apollo-cmpexe". To produce just 68020/68030 On a 68020/68030 node running SR10.1, type executables "build-apollo-emacs". To produce just PRISM On a PRISM node running SR10.1, type executables "build-apollo-emacs". To produce SR9.7 executables Make sure the file "/sys/ins/gpr.ins.c" has return types of gpr_$pixel_value_t for the functions gpr_$inq_foreground and gpr_$inq_background. The version shipped with SR9.7 incorrectly has the return types as void; the version in SR9.7.1 is correct. Then type "source build-apollo-emacs" in a 4.2BSD csh on a node running SR9.7. To produce executables to run Remove "-A cpu,3000" and "-M3000" from on obsolete 68010 machines "build-apollo-emacs" and "src/m-apollo.h" and then build according to one of the above recommendations. Note: There is a bug in alloca on SR10.0 on the PRISM. If you need to build Emacs for use under SR10.0 on PRISM, change HAVE_ALLOCA to C_ALLOCA in "src/m-apollo.h" and rebuild. With the GPR support installed, GNU Emacs integrates well into the Apollo Domain environment. GNU Emacs windows can be moved or resized using the appropriate Display Manager commands, and a Domain cursor is used for mouse operations in addition to GNU Emacs's own block cursor which is used for character operations. GNU Emacs also correctly handles being obscured by other Domain windows. On color nodes, Emacs uses red character and mouse cursors that, unlike the Domain cursor, do not obscure the underlying character. Commands have also been added to GNU Emacs to support the Apollo environment. See the "GNU Emacs Extensions" section below for a description of these extensions. On SR10.1, GNU Emacs state is dumped during the building process to produce a new COFF file, just as on most other UNIX systems. On SR9.7, GNU Emacs is dumped during the building process by creating a freeze file containing all of Emacs's impure state; the freeze file is called "emacs.dump" and is stored in the "etc" directory named by PATH_EXEC in "paths.h". To save space installing Emacs, while still allowing nodes to execute Emacs if the file server is down, I recommend installing Emacs as follows. The file server, or other centralized repository, should have a copy of the entire "/gnuemacs" tree. On user nodes, it is sufficient to create symbolic links from "/gnuemacs/info" to "//file_server/gnuemacs/info" and from "/gnuemacs/lisp" to "//file_server/gnuemacs/lisp" and to have local copies of the following files: /gnuemacs/APOLLO.README /gnuemacs/etc/movemail /gnuemacs/emacs /gnuemacs/etc/COPYING /gnuemacs/etc/apollo.elc /gnuemacs/etc/DISTRIB /gnuemacs/etc/apollo.icons /gnuemacs/etc/DOC-18.54.0 /gnuemacs/etc/env /gnuemacs/etc/GNU /gnuemacs/etc/etags /gnuemacs/etc/NEWS /gnuemacs/etc/loadst /gnuemacs/etc/TUTORIAL Note: "/gnuemacs/etc/emacs.dump" is also needed on SR9.7 systems. By preloading a large number of libraries in "site-load.el", user nodes can run Emacs even if the file server goes down with little probability they will need to load a library that is not already present; loading many libraries increases the size of the freeze file by only a small amount. With installation by this method, GNU Emacs only requires about 1.5mb of disk space on user nodes. Note that in order for dumped Emacs's to function properly on SR9.7, you must have the Domain csh variable "inprocess" unset, so that executing Emacs causes a fresh process to be created, and hence causes Emacs to be loaded at the same point in memory as when it was dumped. For this reason, you must also have "inprocess" unset when you make Emacs. GNU Emacs cannot be suspended with C-Z or C-X C-Z. Therefore, the low level suspension primitive has been redefined to make the window Emacs is in an icon. For this reason, I recommend using key definitions similar to the following to make using Emacs easier: For SR10.1: kd F2 CP /gnuemacs/emacs -N Emacs; WC -A ke kd F3 WI Emacs -W; ICON Emacs -W; WP Emacs -T ke For SR9.7: kd F2 CP /bin/start_csh -N Emacs; WC -A; ES '/gnuemacs/emacs'; EN ke kd F3 WI Emacs -W; ICON Emacs -W; WP Emacs -T ke This defines the F2 key to create a new Emacs in a window named Emacs and defines the F3 key to either un-ICONize the Emacs window, make the Emacs window visible, or POP the Emacs window, whichever is necessary. On SR9.7, running Emacs in a 4.2BSD csh is necessary for proper operation; if your SYSTYPE is not set to "bsd4.2", you must change the above "start_csh" command from "/bin/start_csh" to "/bsd4.2/bin/start_csh". When Emacs is made into an icon, it will attempt to use the icon font in "etc/apollo.icons". If the icon font does not exist, it will be created on demand from "etc/apollo.icons.u" is that file exists; this is done because SR9.7 Apollo font files are difficult to distribute via tar. For an annotated list of files changed or created at Lucid, see the file LUCID-FILES. The original distributed versions of the changed files are also included under the name "foo-" (in case you have a different version of GNU Emacs). As provided, GNU Emacs must be installed (or at least accessible via a link) as "/gnuemacs". To install Emacs in a different directory, you must edit the "paths.h" file and re-make Emacs. Key Bindings There are three classes of key bindings made available by the Apollo support. The first class are direct translations made in the C code that handles input from the keyboard. These translations cannot be overridden without recompiling Emacs, except for the choice of Meta Key: Apollo Keystroke Emacs Keystroke BS DEL DELETE DEL CR RET TAB TAB RIGHT BOX ARROW This key functions as a META KEY. Pressing CTRL followed by RIGHT BOX ARROW does not give a C-M- command on the Low-Profile Keyboard Model I; it works correctly on a Low-Profile Keyboard Model II. Pressing META first and then CTRL always works. See below for instructions on changing the choice of META KEY. The second class of key bindings are bindings of function keys and mouse buttons that do not conflict with the uses of these keys by the Display Manager (i.e., the Display Manager definition would be meaningless within Emacs). Note that unlike the Display Manager, Emacs supports both a character cursor and a mouse cursor. This means that commands below that refer to the "point" use the position of the character cursor, while those which refer to the "mouse cursor" use the position of the mouse cursor. Unlike in the Display Manager, merely moving the mouse cursor in Emacs does not move the character cursor as well; you must click the left mouse button to move the character cursor. For example, moving the mouse cursor and pressing Shift READ will not have the intended effect; you must first press the left mouse button to move the character cursor. MOUSE LEFT DOWN Move point to the location of the mouse cursor Used in conjunction with MOUSE LEFT UP. MOUSE LEFT UP Set the mark and move point to the location of the mouse cursor. Used in conjunction with MOUSE LEFT DOWN so that pressing the left mouse button, moving the cursor, and releasing the left mouse button leaves the mark set to the initial position and the point set to the final position. Useful for easily marking regions of text. If the left mouse button is pressed and released at the same place, the mark is left at the original position of the character cursor. MOUSE MIDDLE DOWN Move point to the location of the mouse cursor and cut the region to the default DM paste buffer. Used in conjunction with MOUSE MIDDLE UP. MOUSE MIDDLE UP Move point to the location of the mouse cursor and paste in the default DM paste buffer. Used in conjunction with MOUSE MIDDLE DOWN so that pressing the middle mouse button kills text and releasing the middle mouse button yanks the text into its new home. MOUSE RIGHT DOWN Perform a find-file on the file name that the mouse cursor points at. Trailing "*" and "@" characters are ignored so that "ls -F" output may be used easily. Shift TAB TAB Control TAB TAB MARK Set the mark. INS Toggle overwrite mode. LINE DEL Kill the whole line containing point. Shift LINE DEL Yank the last killed text. CHAR DEL Delete the following character. Shift CHAR DEL Delete the following character. COPY Copy the region to the default Apollo paste buffer. CUT Cut the region into the default Apollo paste buffer. PASTE Paste in the default Apollo paste buffer. UNDO Undo the last command. GROW Grow Emacs's Apollo window with rubberbanding. MOVE Move Emacs's Apollo window with rubberbanding. LEFT BAR ARROW Move point to the beginning of the current line. RIGHT BAR ARROW Move point to the end of the current line. LEFT BOX ARROW (ignored) UP ARROW Move point vertically up to the previous line. (This key always performs the same command as C-N). Shift UP ARROW Scroll the window down one line. RIGHT BOX ARROW (default META KEY; otherwise ignored) LEFT ARROW Move point left one character. (This key always performs the same command as C-B). Shift LEFT ARROW Move backward to the beginning of a word. RIGHT ARROW Move point right one character. (This key always performs the same command as C-F). Shift RIGHT ARROW Move forward to the end of a word. UP BOX ARROW Scroll down. Shift UP BOX ARROW Go to the beginning of the buffer. DOWN ARROW Move point vertically down to the next line. (This key always performs the same command as C-N). Shift DOWN ARROW Scroll the window up one line. DOWN BOX ARROW Scroll up. Shift DOWN BOX ARROW Go to the end of the buffer. AGAIN Copy the remainder of the current line to the end of the buffer. This is particularly useful in Shell buffers. Shift READ Perform a find-file on the file name where point is. Trailing "*" and "@" characters are ignored so that "ls -F" output may be used easily. SAVE Save the current buffer. EXIT Kill current buffer after saving changes. ABORT Kill current buffer without saving changes. HOLD (ignored) The third class of key bindings are bindings of function keys and mouse buttons that do conflict with the uses of these keys by the Display Manager (i.e., the Display Manager definition is such that some users will want to have the Display Manager command available from within Emacs, and other users will want to have the function key preempt the Display Manager and invoke an Emacs command). For this reason, this class of key bindings are only made if the variable *preempt-display-manager-bindings* is non-NIL. Set this variable non-NIL in your ".emacs" file if you want these key bindings available in Emacs: Shift LEFT BAR ARROW Go to the beginning of the buffer. CMD Execute Display Manager Command. Shift RIGHT BAR ARROW Go to the end of the buffer. NEXT WINDOW Select other window. Shift NEXT WINDOW Delete window. SHELL Run an inferior Shell. READ Edit File but mark file read-only. EDIT Edit File. HELP Prompt for topic and find the Apollo help file. Since users of GNU Emacs may desire similar key bindings when using the Display Manager, a simple set of Emacs-like key bindings for the DM is provided in the file "startup_dm.all" included with GNU Emacs. It may be installed by causing one's normal startup_dm. file to execute it via the CMDF DM command. In addition to these Apollo-specific key bindings, there is TAB filename completion and a new command history for use in Shell Mode and Inferior Lisp Mode. In Shell Mode and Inferior-Lisp Mode, a history of commands typed by the user is automatically maintained, and can be cycled through by M-P (backward) or M-N (forward). Type a prefix of a previously typed command and M-P and the remainder of the command will be inserted. Giving an argument to M-P will cause it to prompt for a regular expression, which will be used for searching the command history. Only commands longer than two characters and less than *saved-commands-length-limit* will be kept. The Info system has also been extended with a command to create a new node. GNU Emacs Extensions The following functions and variables are extensions to the normal GNU Emacs primitives to support the Apollo environment (the functions below may be called either programatically as Lisp functions or interactively as commands): apollo-keyboard-type () This function returns as an integer the number of the keyboard type attached to the node on which Emacs is running. The keyboard type numbers are: 1, for the High-Profile Keyboard; 2, for the Low-Profile Keyboard Model I; and 3, for the Low-Profile Keyboard model II. bind-apollo-function-key (function-key binding &optional meta-binding) This function enables the Apollo Function Key defined by the string function-key and binds the normal keystroke to binding and the meta keystroke to meta-binding. If meta-binding is unspecified, binding is used for both the normal and meta keystrokes. See the variable *apollo-function-keys* in "etc/apollo.el" for the legal function keys. unbind-apollo-function-key (function-key) This function disables the Apollo Function Key defined by the string function-key and returns control of the Function Key to the Display Manager. See the variable *apollo-function-keys* in "etc/apollo.el" for the legal function keys. bind-apollo-mouse-button (mouse-button binding &optional meta-binding) This function enables the Apollo Mouse Button defined by the string mouse-button and binds the normal use of mouse-button to binding and the meta use of mouse-button to meta-binding. If meta-binding is unspecified, binding is used for both the normal and meta mouse-buttons. See the variable *apollo-mouse-buttons* in "etc/apollo.el" for a list of all the legal mouse buttons. unbind-apollo-mouse-button (mouse-button) This function disables the Apollo Mouse Button defined by the string mouse-button and returns control of the Mouse Button to the Display Manager. See the variable *apollo-mouse-buttons* in "etc/apollo.el" for a list of all the legal mouse buttons. select-apollo-meta-key (meta-key) This function allows you to select which key is used as a Meta Key for Emacs. The selection is made by specifying the name of the function key for the down key transition. See the variable *apollo-mouse-buttons* in "etc/apollo.el" for a list of all the legal functions keys; any function key that provides separate up and down transitions may be used as the Meta Key. select-apollo-protection-style (protection-style) This function causes Emacs to use Domain ACL protection if the protection-style argument is non-NIL and UNIX Mode protection if the protection-style argument is NIL. GNU Emacs can either use UNIX file modes or Domain ACLs to control the access rights to files it writes. By default, UNIX modes are used just as when Emacs runs on other UNIX systems. If Domain ACL style protection is enabled, Emacs will not use the chmod system call, and so files will be written using the default ACL for the directory in which they are created. execute-dm-command (dm-command) This function passes the string dm-command to the Display Manager for execution. backup-by-copying-when-mismatch This variable normally controls whether backup files should be created by renaming or copying. When non-NIL, if renaming to create a backup file would cause the owner or group of the file to change, then the backup file is created by copying so that the owner and group are preserved. On the Apollo, this variable has another function as well. Because Domain/OS has a typed file system, setting this variable non-NIL causes copying to also be done if the Domain/OS type of the file is not one of the default types (unstruct or uasc). Thus setting this variable non-NIL guarantees that the Domain/OS type of a created backup file will match the Domain/OS type of the parent file. *apollo-key-bindings-hook* This variable, if set non-NIL in your ".emacs", should be a function to call after the default Apollo key bindings are set up. Because the file "etc/apollo.el" is loaded after your ".emacs", this variable is needed so that you can customize the Apollo key bindings. *preempt-display-manager-bindings* This variable, which defaults to NIL, controls whether or not key bindings are made which conflict with those of the Display Manager. Set this variable non-NIL in your ".emacs" to enable the key bindings described above that conflich with Display Manager key bindings. The following low-level functions are used to implement the above functions. enable-apollo-function-key (function-key-code) This function enables the Apollo Function Key Transition defined by the integer argument function-key-code. See "/usr/include/apollo/kbd.h" (SR10.1) or "/sys/ins/kbd.ins.c" (SR9.7) for definitions of the key transition codes; the function-key-code argument must be greater than or equal to 0x80. This is a low-level function whose primary purpose is to implement bind-apollo-function-key. When an Apollo Function Key Transition is enabled, Emacs takes control of the function key away from the Display Manager, and subsequent uses of that function key cause no Display Manager action to be taken, but do cause Emacs to see the character sequence M-* as input (if the Meta Key is also depressed, then the character sequence is M-+ ). Note that in order to use a function key within Emacs, two operations must be performed: the key must be enabled for use by Emacs, and the M-* and M-+ keystroke sequences must be bound to Emacs functions. The function bind-apollo-meta-key encapsulates all three operations. disable-apollo-function-key (function-key-code) This function disables the Apollo Function Key Transition defined by the integer argument function-key-code. When an Apollo Function Key Transition is disabled, Emacs returns control of the key to the Display Manager, and subsequent uses of that function key cause no Emacs input characters to be seen, but do cause any assigned Display Manager action to be taken. enable-apollo-mouse-button (mouse-button-code) This function enables the Apollo Mouse Button Transition defined by the integer argument mouse-button-code. The down key codes for the Left, Middle, and Right mouse buttons are the ASCII codes for 'a', 'b', and 'c'. The up transition key codes are the ASCII codes for 'A', 'B', and 'C'. The codes for 'd' and 'D' may be used if you have a four button mouse. This is a low-level function whose primary purpose is to implement bind-apollo-mouse-button. When a Mouse Button Transition is enabled, Emacs takes control of the mouse button away from the Display Manager, and subsequent uses of that mouse button cause no Display Manager action to be taken, but do cause Emacs to see the character sequence M-* as input (if the Meta Key is also depressed, then the character sequence is M-+ ). The offset of 8 is necessary to avoid C-G characters as input. Note that in order to use a mouse button within Emacs, two operations must be performed: the mouse button must be enabled for use by Emacs, and the M-* and M-+ keystroke sequences must be bound to Emacs functions. The function bind-apollo-mouse-button encapsulates all three operations. disable-apollo-mouse-button (mouse-button-code) This function disables the Apollo Mouse Button Transition defined by the integer argument mouse-button-code. When an Apollo Mouse Button Transition is disabled, Emacs returns control of the mouse button to the Display Manager, and subsequent uses of that mouse button cause no Emacs input characters to be seen, but do cause any assigned Display Manager action to be taken. set-apollo-meta-key (meta-key-code) This function allows you to select which key is used as a Meta Key for Emacs. The selection is made by specifying the transition key code for the down key transition; the necessary key codes for the shifted, control, and up transitions are derived from the down key transition. This is a low-level function whose purpose is to implement define-apollo-meta-key. In addition to the functions described here, you should also consult the file "etc/apollo.el" for additional functions that may be useful. This file is normally loaded automatically when Emacs is run on an Apollo; it defines the commands and key bindings that are not implemented directly by C code. Acknowledgements The following people have contributed ideas that have helped make this interface possible: Nathaniel Mishkin, Rob Stanzel, and Mark Weissman of Apollo Computer, Dave Holcomb of CAECO, Vincent Broman of NOSC, and J. W. Peterson of the University of Utah. From apollo-request@umix.cc.umich.edu Thu Sep 21 11:35:36 1989 Date: 19 Sep 89 14:47:00 GMT From: mishkin%apollo.uucp@eddie.mit.edu (Nathaniel Mishkin) Organization: Apollo Computer, Chelmsford, MA Subject: Re: IOS Problem (long) Message-Id: <45bb826b.1d6d5@apollo.HP.COM> References: <8909151401.AA04534@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8909151401.AA04534@umix.cc.umich.edu> derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") writes: >Here's a hopefully basic IOS question someone can address. >I'm creating a REC type file with 4 byte records. Prior >to closing the file, I can check and verify that the records >are 4 bytes. When I reopen the file, the records are 44 bytes. > >I assume I'm doing something trivially wrong. A sample >program and its output are shown below. The offending line is: > > /* Reopen, again seek to same location, and check length */ > file0 = ios_$open("/user_temp/file0", strlen("/user_temp/file0"), ios_$no_open_options, status); The problem is that "strlen" returns a long and the 2nd param to "ios_$open" is a short. The net effect is that "ios_$open" sees a name length of 0, and opens the current working directory (please don't ask why opening the null string is treated like opening "."). It's all downhill from there. I don't know if it's an option in your case, but in general, I strongly recomment people use the ANSI/C-ized ".h" files ("" in this case), since they make these sorts of problem go away (or at least use of them results in the compiler telling you what wrong thing you're doing). -- -- Nat Mishkin Hewlett Packard Company / Apollo Systems Division mishkin@apollo.com From apollo-request@umix.cc.umich.edu Thu Sep 21 11:39:07 1989 Date: Thu, 21 Sep 89 10:04:17 EDT From: pha@caen.engin.umich.edu (Paul H. Anderson) Message-Id: <45c56d781.000f088@caen.engin.umich.edu> To: apollo@umix.cc.umich.edu, weiner%novavax%uflorida%uakari.primate.wisc.edu%uwm.edu%gem.mps.ohio-state.edu.uucp@tut.cis. Subject: Re: New Apollo Workstation? From: weiner%novavax%uflorida%uakari.primate.wisc.edu%uwm.edu%gem.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu Organization: Motorola Inc. Subject: Re: New Apollo Workstation? In article <16462@watdragon.waterloo.edu> dvadura@watdragon.waterloo.edu (Dennis Vadura) writes: In article <8909151903.AA08561@richter.mit.edu> krowitz@RICHTER.MIT.EDU (David Krowitz) writes: >deleted hardware description ... > This sounds nice, but what about software? Is it going to be as expensive as the regular distribution? An Apollo SE today told me that the new model DN2500 requires SR10.2 to run! SR10.2 might not ship until early next year (increased quality audits under the HP way, I understand). This means that only sales units and demo units with beta SR10.2 software will be shipping very soon. The main reason a new release is needed is that the /sau?? system specific software is different. -- Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner (407) 738-2087 The information I have is that the DN2500 will run SR10.1 with a PSK that gets shipped with the 2500. PSK stands for product service kit, and is used to provide small updates to the OS to handle new hardware. Paul Anderson CAEN From apollo-request@umix.cc.umich.edu Thu Sep 21 13:47:31 1989 Date: 21 Sep 89 12:14:53 GMT From: shull%scrolls.wharton.upenn.edu%netnews.upenn.edu%eecae%tank.uucp@handies.ucar.edu (Christopher E. Shull) Organization: desci Subject: Re: New Apollo Workstation? Message-Id: <14638@netnews.upenn.edu> References: <8909151903.AA08561@richter.mit.edu>, <16462@watdragon.waterloo.edu>, <1468@novavax.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1468@novavax.UUCP> weiner@novavax.UUCP (Bob Weiner) writes: >An Apollo SE today told me that the new model DN2500 requires SR10.2 to >run! SR10.2 might not ship until early next year (increased quality >audits under the HP way, I understand). This means that only sales >units and demo units with beta SR10.2 software will be shipping very >soon. The main reason a new release is needed is that the /sau?? system >specific software is different. >-- >Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner >(407) 738-2087 My sales dude, who is usually straight with me, says that there is to be an SR 10.1.+ / SR 10.2.- released with the DN2500. Furthermore, he says this implies that you will need at least one disked DN2500 before adding diskless nodes. Still, the box seems very interesting to me. My question is this though: what is the speed of the SCSI drive with respect to both access time and transfer rate? Better or worse than the ESDI's and by what percentage? -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 Thu Sep 21 17:58:43 1989 Date: Thu, 21 Sep 89 15:01:09 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8909211901.AA01159@richter.mit.edu> To: apollo@umix.cc.umich.edu, shull%scrolls.wharton.upenn.edu%netnews.upenn.edu%eecae%tank.uucp@handies.ucar.edu Subject: Re: New Apollo Workstation? I had a presentation on the DN2500 just yesterday at Chelmsford from one of the product managers. The DN2500 is simply yet another 68020/68030 based Apollo workstation. All it requires is that the disk it is booting off of has the /sau9 directory installed. This directory is included in SR10.2 and is available as a product support kit (PSK) for SR10.1. If the DN2500 is diskless, then it's partner node can be any Apollo node running SR10.1 with the PSK installed or SR10.2. As for delivery dates, they said 45-60 days from receipt of order. Demand for the machines seems to be high. I suspect that the longer you wait before placing an order, the longer the lead time will get. These things are much less expensive than a comparable Macintosh system (even with MIT's volume discounts from Apple). -- 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 Sep 21 18:04:34 1989 Date: 21 Sep 89 12:48:40 GMT From: ccsmm%gdt%dcl-cs%ukc%mcsun.uucp@uunet.uu.net (Martin Maclaren) Organization: University of Bath, England Subject: r/w ms-dos disks Message-Id: <1989Sep21.124840.21282@gdt.bath.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I remember a small discussion some time ago in this group about reading and writing to ms-dos (v3.3) disks from an apollo - I don't remember what the outcome was. Is it possible? Could someone mail me any info on the subject. (We've SR9.7 at the mo, and DN3000's) Ta, Martin From apollo-request@umix.cc.umich.edu Thu Sep 21 18:06:57 1989 Date: 21 Sep 89 07:32:30 GMT From: news%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%gryphon%hacgate%usc.uucp@apple.com (Dave Hayes) Organization: Jet Propulsion Laboratory Subject: INPROT, ACL's, and the great system guru in the sky Message-Id: <1989Sep21.073230.13104@elroy.jpl.nasa.gov> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Well, I am now deeply immersed in the SR10.1 experience. Here it is, 1AM after my second-and-a-half system regeneration from media and I am still waiting to get a "clean" OS on my hard disk. WHY did I regen the system twice and a half? One word: ACL'S!! Did you all know that INPROT has no template files? I'm sure you did (why just last week someone asked about this), but this is no big deal if you want to run a wide-open system. HOWEVER....if you need to have a closed system (like if you are hooking up to the Internet or something useful like that) then you are really pre...er...out-of-luck. Because of the lack of templates, you have no way of knowing the correct ACL state of your OS. This can present a problem. For example, most UNIX people close up rights to everything in /dev as a security measure. IF, however, you close up an SR10 /dev...well let's just say that your OS doesn't work anymore. Ok...so that's not too much of a problem, right? You can always UNacl dev. But /sys/subsys/login? INPROT (and ACL too) seems to delete the subsystem status of this file. Basically that causes problems with CRP. To fix this, one must have a copy of the file (with correct ACL's and Subsystems) located elsewhere...preferably on another node...but unfortunately on media if you happen to try and INPROT the first SR10 node. WHY ARE THERE NO TEMPLATE FILES FOR INPROT??? They were provided at SR9.7 (as part of the install software), why did they suddenly disappear? Is there a chance of getting a template for a closed system sometime in the near future? Knowing just how tightly your OS can be ACL'd shouldn't have to be a hacking experience. Someone should be able to tell you. Preferablyt the authors of the OS..... ============================================================================== Dave Hayes - Jet Propulsion Laboratory - dave%jplopto@jpl-mil.jpl.nasa.gov ------------------------------------------------------------------------------ The above e-mail address will hopefully be changed someday to the APOLLOs that I work on. Until then....*sigh*....c'est la vie. ============================================================================== From apollo-request@umix.cc.umich.edu Thu Sep 21 19:46:47 1989 Date: 21 Sep 89 17:08:00 GMT From: oj%apollo%hp-sdd%ncr-sd%ncrlnk.uucp@uunet.uu.net (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: SR10.1 vt100 problem Message-Id: <45c6121c.208ba@apollo.HP.COM> References: <254@cipher.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <254@cipher.UUCP> rgs@cipher.UUCP (Bob Schultz) writes: > >We repeatedly get "Cannot create vt100 window" when first trying to >execute vt100, however vtserver does get started and continues to run. This problem is known (to me, anyhow). I'm not sure how widespread it is. Your best bet for a fix is to execute the following commands to see what versions of code you're running. /usr/apollo/bin/ts /lib/gprlib /lib/streams /lib/clib /sys/vtserver /usr/apollo/bin/ts /usr/X11/bin/Xapollo /sys/dm/dm Please call your customer service person with the results of these commands, and they should be able to help... /Ollie Jones (speaking for myself, not for HP Apollo Systems Division) From apollo-request@umix.cc.umich.edu Fri Sep 22 07:28:41 1989 Date: 20 Sep 89 17:28:31 GMT From: larry%larry.fpssun.fps.com%nosun%cvedc%ogccse%unmvax.uucp@ucbvax.Berkeley.EDU (Larry Breniser ext 2282) Organization: Floating Point Systems Subject: expired logins Message-Id: <565@larry.fpssun.fps.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Is there a way to keep logins from being expired under sr 9.7? Larry From apollo-request@umix.cc.umich.edu Fri Sep 22 21:24:15 1989 Date: 22 Sep 89 20:39:11 GMT From: kts%quintro%tiamat.uucp@uunet.uu.net (Kenneth T. Smelcer) Organization: none Subject: RN changes for Apollo? Message-Id: <1989Sep22.203911.493@quintro.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In the past, various people have mentioned that they've patched 'rn' so it won't keep the active file locked all the time. I've looked at the code and can't find any explicit locking, and I don't know enough about the Apollo networking system calls to remove/release the Concurrency lock that the OS puts on any open file. Could someone post/mail me a method for fixing this locking problem? Thanks! -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ken Smelcer Quintron Corp. quintro!kts@lll-winken Quincy, IL tiamat!quintro!kts@uunet From apollo-request@umix.cc.umich.edu Fri Sep 22 21:25:58 1989 Date: 21 Sep 89 17:31:47 GMT From: rhaslam%esunix%uplherc%hellgate.utah.edu%helios.ee.lbl.gov%pasteur.uucp@ucbvax.Berkeley.EDU (Reed Haslam) Organization: Evans & Sutherland, Salt Lake City, Utah Subject: Apollo DN4000 series workstations for sale. Message-Id: <1543@esunix.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Evans and Sutherland has two (2) Apollo workstations that we will sell to the highest bidder. The systems are configured as follows: System A -------- - Apollo DN4500. 16MB memory, 8-bit Color, 19" monitor, 320MB winchester disk, cartridge tape, domain ring interface, ethernet interface. 1 set Apollo SR10 documentation. Serial Number - A00263312 Minimum Bid $ 15,500 System B -------- - Apollo DN4000, 8MB memory, 8-bit Color, 19" monitor, No disk, No tape, ethernet interface. 1 set Apollo SR10 documentation. Serial Number - A00270399 Minimum Bid $ 3,200 ------------ Bidders may bid on the units separately. All bids must be received by 5:00 P.M. Friday Sept 30, 1989. Bids should be sent to: Barbara Bohling Evans & Sutherland Computer Corporation 600 Komas Drive Salt Lake City, Utah 84108 The equipment will be sold "as is". Systems will be under Apollo maintenance until we ship them to the successful bidder. We've not had any problems with the hardware in these systems over the past year (the 4500 was a 3550 which was upgraded). Purchaser will pay freight charges and the systems must be paid for before we ship them. Payment will be required by October 6 and we will ship the units to the successful bidder the week of October 9-13. -Reed B. Haslam- Evans & Sutherland Computer Corporation Simulation Division 600 Komas Drive Salt Lake City, Utah 84108 (801)-582-5847 x3344 From apollo-request@umix.cc.umich.edu Fri Sep 22 21:26:04 1989 Date: Fri 22 Sep 89 16:25:38-PST From: Steve Albrecht Subject: Apollo DN2500 shown at Seybold Conference To: apollo@umix.cc.umich.edu Message-Id: <622509938.750000.ALBRECHT@CALIPH> Mail-System-Version: Apollo Computer introduces new workstation for less than $4000 -------------------------------------------------------------- Last night, Apollo unveiled their new low-end UNIX workstation to the public. The DN2500 workstation will be available in Q4/89 with a base price of $3900 for the following configuration: o 20MHZ 68030 cpu (4 MIPS) o diskless o 4MB memory o 15" monochrome display (1024 x 800 resolution) o choice of one: EtherNet, IBM Token Ring, or Apollo Ring o 7-device SCSI adapter (primarily for disk and tape devices) o 1 serial port o 1 parallel printer port (some doubt whether there is even one!) Here is the list of configuration and expansion options: o RAM memory to 16MB o 1 or 2 disks, or 100MB or 200MB capacity each internally. ..... $1500 for each 100MB disk, $3500 for each 200MB disk o Total addressable disk space(internal + external) is 660MB(some doubt here) o External 1/4" cartridge tape (40MB or 60MB) o 19" monochrome (1280 x 1024 resolution) .... ($1500 more for this) Limitations of the DN2500: o No color, ever! o No ESDI disks (ever?) o no apparent way to add additional serial or parallel ports o no internal cartridge tape possible o little or no internal bus slots (unsure, but box is very small) Software compatibility/availability o Binary-compatible with other Apollo 680x0 nodes (closest to DN3500) o Designed to run Domain/OS 10.2 (which includes X-Windows) o Will initially ship with Domain/OS 10.1 and PSK #25 to patch 10.1 for hardware differences o I did not get hard assurances, but the indication was that anything that runs under 10.1 on a DN3500 will run on the DN2500 with the PSK. (::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::) ) 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 Sat Sep 23 11:38:33 1989 Date: 22 Sep 89 17:58:34 GMT From: Chuck_SirVAX_Staatse%cup.portal.com%portal.uucp@uunet.uu.net Organization: The Portal System (TM) Subject: Want to Buy Used Apollo Workstations Message-Id: <22411@cup.portal.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu $$$$$$ WANTED $$$$$$ $$$$ USED APOLLO SERIES 3000 AND SERIES 4000 WORKSTATIONS $$$$ I am interested in buying a used Apollo Series 3000 workstation and a used Apollo Series 4000 workstation. Each workstation should have approximately 4 megabytes of memory, a monochrome monitor, Apollo software and utilities, and complete hardware and software documentation. I am flexible on the hardware configuration of the workstations. If you have equipment to sell, please send your name, address, phone number, workstation configuration information, and asking price. Or call our purchasing department at 609-799-0071 ext. 362. From apollo-request@umix.cc.umich.edu Sat Sep 23 22:39:09 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8909240058.AA00678@icaen.uiowa.edu> Date: Sat, 23 Sep 89 19:19:50 CDT Subject: Re: Apollo DN2500 shown at Seybold Conference To: apollo@umix.cc.umich.edu WRT posting: <622509938.750000.ALBRECHT@CALIPH> > Last night, Apollo unveiled their new low-end UNIX workstation to > the public. The DN2500 workstation will be available in Q4/89 with > a base price of $3900 for the following configuration: Actually the first public showing of the DN2500 was at the ADUS conference in New Orleans on Tuesday night (9/12). > o 1 serial port > o 1 parallel printer port (some doubt whether there is even one!) The DN2500 has no parallel printer port but 3 serial ports ala the DN3500. IE there is one DB25 socket on the machine but you can add the optional expander "pig-tail" to use all 3 ports. > Limitations of the DN2500: > > o No color, ever! > o No ESDI disks (ever?) > o no apparent way to add additional serial or parallel ports > o no internal cartridge tape possible > o little or no internal bus slots (unsure, but box is very small) True, no color, no ESDI disks, no internal add in capability beyond the memory "sim" sockets and the SCSI disks. There is one AT-bus slot but that's where the network controller goes, and it's not optional. However, you can connect up external SCSI devices, Apollo currently provides support for disk, C-tape, M-tape (?), and V-tape. In the sr10.2 GPIO package there is support for user written device drivers to talk to external devices on the SCSI bus. Thus you could add any SCSI device that doesn't conflict with an Apollo device. The bottom line is that this was designed for the lowest cost for a general usage machine. We are a "seed" site for the DN2500 and have had one for about a month. So far, it has worked with everything that we've hit it with (except for bugs in the beta-1 sr10.2). It feels like 80% to 85% of a DN3500. IE based upon various benchmarks, the CPU speed, disk speed, display update speed all seem within 80% to 85% of comparable things on a DN3500 with the same amount of RAM (8mb) and a 348 FA disk. For the price, this is good performance. You may wonder how a 20MHZ 68030 cpu (DN2500), which is exactly 80% of a 25MHZ 68030 cpu (DN3500), can have a thru-put of better than 80% for some operations. The answer is that they were able to design out some hardware delays when they left behind all the baggage needed to support the AT-bus I/O for general devices. Thus connections between CPU, memory, display hardware, and the SCSI controller are tighter and for some kinds of operations are faster. Dave Funk From apollo-request@umix.cc.umich.edu Sun Sep 24 00:39:49 1989 Date: 12 Sep 89 08:21:02 GMT From: solomon%mdcbbs.uucp@uunet.uu.net (BARRY (MCDONNELL DOUGLAS)) Organization: MDM&E Subject: Re: /com/sh programming Message-Id: <389@mdcbbs.uucp> References: <8909071944.AA13986@richter.mit.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu > I want to write an Aegis shell script that checks if a > previously executed command completed correctly. If I > remember correctly, programs which run to completetion > return the status code PGM_$OK. Does anyone know how > I can test for this within a shell script? It's actualy simpler than that. #!/com/sh if then else endif Barry Solomon (Mcdonnell Douglas M&E) Date: 26 Sep 89 05:00:17 GMT From: watcher@athena.mit.edu (chris ross) Organization: codex corp. Subject: sr9 local unix mail problem (resolved) Message-Id: <14655@bloom-beacon.MIT.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Recently, someone posted an article describing a bug in sendmail at SR9.7, whereby mail could be sent off-site, but not to any local user. I can't remember who it was, and the article has expired at this site, so I'm posting a fix. At least one of the SR9.x Domain/IX installation scripts fails to properly set owners and setuid bits on several key programs, such as su, login, and... /bin/mail. Thus, mail can't write to /usr/spool/mail. Naturally, sendmail tries to return error mail, invoking the local mailer (guess who) to deliver it... Resetting the owner (root) and setuid bit fixes this. _________________________________________________________________ chris ross <0> uunet!codex!watcher or watcher@athena.mit.edu From apollo-request@umix.cc.umich.edu Tue Sep 26 05:24:53 1989 Date: 26 Sep 89 04:39:34 GMT From: watcher@athena.mit.edu (chris ross) Organization: codex corp. Subject: apollo netnews summary (brief) Message-Id: <14654@bloom-beacon.MIT.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Several weeks ago I submitted an article requesting information about UseNet software for Apollos. I received responses from the following people: Tim Barrios David Boreham Keith Cantrell Dave Clemans Dennis Cottel I attempted to reply to all messages received, but some replies seem to have disappeared into limbo (i.e., no response from the other end, and no mailer errors.) The impression I get is that both B and C news will work under SR10.1 with only minor modifications. The most notable problem is that of multiple writers to the active news file -- Aegis does not permit cowriters access from different nodes. I'd like to describe my own experiences with the news software, except I haven't put it together yet; my responsibilities as an application programmer are taking up all my time at present (and the "official" sysads either don't know C or Unix or don't care about UseNet. Grrr.) In addition, given the number of bugs I've found in SR9.7 and 10.1, I may wait until SR10.2 to tackle it. Listed after my .sig are excerpts from the messages I received. The total volume is sufficiently small to not require a detailed summary on my part. Thanx to all who replied. I'll be in touch when I get it running. ________________________________________________________________ chris ross <0> uunet!codex!watcher or watcher@athena.mit.edu ==================== From: asuvax!gtephx!barriost@ncar.UCAR.EDU (Tim Barrios) Date: Thu, 24 Aug 89 08:22:43 mst we are using a version that our local Apollo office got for us from the Seattle office (i think). it has some problems. for example, notice that this mail (and my postings) come from my actual node name ('louisiana') rather than the name of our usenet site ('gtephx'). [in a later message] the actual node only appears on postings, i guess. we have fixed our sendmail file (which is why it doesn't show up on the mail) but there is a special constant in the news configuration where you can tell it all of your TCP/IP nodes should come from the same news site. i did re-compile the source to avoid these problems by changing certain defaults but then the 'rnews' of incomming news was taking more than a minute or so to incorporate each news item into our news. the made it so that we could never catch up on incomming news items. [in a later message] i did a LOT different in that version. the biggest difference is that the version i got from Apollo was compiled under BSD and I wanted mine compiled as SysV since we are primarily a SysV site ==================== From: David Boreham Date: Thu, 24 Aug 89 21:03:09 bst We have SR10.1 and 9.7 nodes. The 9.7 do not run news and are due to be upgraded soon. The Apollos run the NNTP version of rn. This compiles fine under SR10.1 (not under 9.7), you need to correct a couple of bugs in the source code---Sun's compiler is less strict than Apollo's. We got the gode off the net (patches to the standard rn source). This NNTP rn gets its stuff over TCP/IP from a big SUN server which holds all the news and does the UUCP business. The only problem I found was that rn does a fancy hack to find the current directory by hopping up the filesystem untill it can't go any higher. Then it cd's back to where it thinks it started from. Unfortunately, with the apollo network root '//', this scheme does not work. All you need to do is select the "don't-use-the-clever-scheme-use-pwd-unstead" option, then correct the bug in the "pwd" code and you're going. ==================== From: attctc!digi!kcantrel@EDDIE.MIT.EDU (Keith Cantrell) Date: Wed, 23 Aug 89 18:23:36 CDT If you are planing to receive news from one of your 10.1 machines, then it does not take much to get just plain bnews-2.11 from run. The same goes for 'rn'. The first problem that I found with both of these were that they expect that if you have the environment variable "ORGANIZATION" set to something, that that is what you want to be in the "ORGANIZATION:" field of the header message of any notes that you post. Unfortunately Apollo defines it to be the organization part of you login. [notes about locking the active file; see next message] ==================== From: dclemans@mentor.com (Dave Clemans @ APD x1292) Date: 23 Aug 89 15:42:15 GMT The big problem you see with the news software on Apollos (provided you set it up so that all the Apollo nodes look like one big "pseudo" machine, which is what most people I've heard of have done) is that the Usenet software expects standard Unix file locking semantics, that is no locking at all. Apollo's enforce exclusive file write access across a network. We run Cnews as the Usenet "transport" service. I didn't have any real problems in bringing the recent release of Cnews up; it's been quite stable. Note that if you compile Cnews as a Sys5 program you WANT to use one of the public domain dbm library emulators; what the Cnews build script gives you by default to replace the standard dbm libraries is an extremely slow sequential search. I have all the "standard" news reading programs up; readnews, vnews, rn and vn. To work around the file locking problems they actually read an "active.copy" file instead of "active". "active.copy" is updated from "active" every 15 minutes by a cron job that runs on our mail/news gateway node. rn was also modified to not hold the active file continually open (which would prevent active.copy from being updated from active...) I tried once to compile nn (under sys5) but it had problems with hanging after reading one character. I haven't had time to look at it to see why, or to try to compile it instead as a bsd program. ==================== From: dennis@peanuts.nosc.mil (Dennis Cottel) Although our experience won't be directly applicable, you might like to know what we are doing. On our network of 40 SR9.7 nodes, we are using two newsreaders via NNTP to our organization's central non-Apollo news server. One is rn; sources came from our local standard BSD4.3 rn distribution modified to run with NNTP, with some minor customizations from Woody Kellum obtained over the network. The other is Kim Storm's nn which ported straight onto the Apollos right out of the box. [note: dennis forwarded woody's changes to me in another message; contact me if you want a copy] From apollo-request@umix.cc.umich.edu Wed Sep 27 10:25:08 1989 Date: 27 Sep 89 02:29:32 GMT From: phcalamai%water%maytag%watmath%att.uucp@ucbvax.Berkeley.EDU (Paul H. Calamai) Organization: U of Waterloo, Ontario Subject: Passwd Etc is bundled with Domain/OS Message-Id: <2672@water.waterloo.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In volume 5, Number 9, page16 of HP Design and Automation (An independent newsmagazine for HP/Apollo workstation users) I noticed an article entitled "Software Manages Network Login, Password Information". This article starts by saying "Apollo Computer Inc. has introduced the Passwd Etc user registry system for NCS." It later claims that "Passwd Etc is bundled with Apollo's Domain/OS operating system and is standard with all Apollo workstations." WHERE DO I SIGN UP !!!!!! Apollo claims that Passwd is a significant enhancement over existing registry management tools for UNIX systems! Thank God. We've had a lot of trouble with the management tools on our 3500 which is connected to a local network that includes other stand-alone Apollo workstations. Does anyone out there know anything significant about Passwd Etc ? Does Apollo now bundle Domain/OS with this tool? What sort of enhancements does it offer? Is there a God? Thanks -Paul From apollo-request@umix.cc.umich.edu Wed Sep 27 18:22:35 1989 Date: 27 Sep 89 14:25:02 GMT From: kleonard%gvlv2.uucp@burdvax.prc.unisys.com (Ken Leonard) Organization: Unisys Defense Systems, NISD, Great Valley Laboratory Subject: info please Message-Id: <341@gvlv2.GVL.Unisys.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu also to: comp.sys.masscomp,comp.dcom.telecom, ------ How do _YOU_ connect "super"-class machines so they can talk to each other (partly?) (almost?) (really?) as fast as they can compute? ------ Who is presently making, using, building, needing, selling... -- a "LAN" in the 1Gb/s class? -- a "CPU cluster" connection, _NOT_ bus-to-bus or manufacturer-specific, in .. the 1Gb/s class? -- an HSC-to-HSC, HSX-to-HSX, or equivalent speed class channel-to-channel .. bridge or switch? -- an HSC- or HSX- or equivalent-to-VME or -Futurebus or -equivalent interface? ------ Is Ultra (Systems Inc.?) actually shipping working systems? Who is using one? How well does it work? ------ Is anyone other than Sandia actually trying to use the "HSC/HSX Hub"? Is anyone planning to use one? ------ ------------------- all responses gratefully received best regardz, Ken Leonard From apollo-request@umix.cc.umich.edu Thu Sep 28 07:30:38 1989 Message-Id: <8909280917.AA28974@umix.cc.umich.edu> Date: Thu, 28 Sep 89 17:10 H From: Subject: printer driver To: apollo@umix.cc.umich.edu X-Original-To: apollo@umix.cc.umich.edu, YEOAK 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 to fix it? Thanks for your help in advance. --AnnKian Yeo Bitnet: yeoak@nusdiscs From apollo-request@umix.cc.umich.edu Thu Sep 28 09:26:46 1989 Date: 28 Sep 89 02:14:27 GMT From: ggarb%apple.com.uucp@apple.com (Gordon Garb) Organization: Apple Computer, Inc. Subject: Re: info please Message-Id: <4429@internal.Apple.COM> References: <341@gvlv2.GVL.Unisys.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <341@gvlv2.GVL.Unisys.COM> kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) writes: > Is Ultra (Systems Inc.?) actually shipping working systems? Who is using one? > How well does it work? We have an Ultra with two frame buffers hooked to our Cray X-MP 48 on an HSX channel. It works well. /Gordon Garb (*I don't know where I got these opinions, but they're mine now. *) From apollo-request@umix.cc.umich.edu Thu Sep 28 09:33:51 1989 Message-Id: <8909281235.AA05383@umix.cc.umich.edu> Date: Thu, 28 Sep 89 08:30 EDT From: FERGUSON%TMASL.EXXON.COM@CORNELLC.cit.cornell.edu Subject: Network Throughput To: apollo@umix.cc.umich.edu X-Vms-To: APOLLO All the salespeople in the world are saying "We'll soon be supporting 100 Mbit/sec Ethernet and FDDI fiber-optic token rings, so buy our machine!" C'mon, you've all heard it. So, where is it? Anyone know what the technology is at this point? How soon can we see FDDI on Apollo workstations? Sending 100 Mbytes @ 50 kbytes/sec via ftp or NFS takes entirely too long. And yes, Apollo Domain Ring is much better than that, but we've been through the proprietary argument enough times. Any comments? Anyone read any interesting articles on FDDI? Anyone ever have a salesman back up his claims with facts? Scott Ferguson Exxon Research & Engineering Annandale, NJ 08801 (201) 730-2339 ferguson@erevax.bitnet From apollo-request@umix.cc.umich.edu Thu Sep 28 11:31:54 1989 Date: 21 Sep 89 05:41:02 GMT From: ljs%nucs.cs.nu.oz%nuts%basser%usage%ccadfa%csc%munnari.oz.au.uucp@uunet.uu.net (Len Sciacca) Organization: Computer Science Dept, Newcastle University, Australia Subject: DP LZR2665, Interleaf, and other lemons Message-Id: <485@nuts.nu.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have a DataProducts LZR2665 laser printer on our Apollo network and have found the print quality very poor. This is especially so with Interleaf. The printer does not seem to handlr downloaded fonts so we use the native fonts of the printer. Have other people found the same problem and if so did they find a fix. One expensive solution is to convert it to a RIPRINT but other packages will not be able to use it. TeX does does work with it either. This printer has been a lemon for us. We wanted it for the A3 postscript capablity. We also have Mentor Graphics s/w which prints poorly on it as well. And yes.. we have had DP here several times to tune it! How about a postscript to RiPrint filter? Is there one available? Thank you in advance.P Len Sciacca Department of Electrical Engineering and Computer Science University of Newcastle, N.S.W., Australia email: ljs@nucs.cc.nu.oz.au From apollo-request@umix.cc.umich.edu Thu Sep 28 17:33:16 1989 Date: Thu, 28 Sep 89 16:19:52 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8909282019.AA09919@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: DN2500 memory Has anyone tried using non-Apollo memories in the new DN2500? 1MBx9 simms seem to go for about $120 each (retail price!) for 8ns memory, less if you can use 100 ns or 120ns chips. -- 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 Sep 28 19:39:42 1989 Date: 28 Sep 89 18:56:38 GMT From: spl@mcnc.org (Steve Lamont) Organization: Foo Bar Brewers Cooperative Subject: Re: info please Message-Id: <5489@alvin.mcnc.org> References: <341@gvlv2.GVL.Unisys.COM>, <4429@internal.Apple.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <4429@internal.Apple.COM> ggarb@apple.com (Gordon Garb) writes: >In article <341@gvlv2.GVL.Unisys.COM> kleonard@gvlv2.GVL.Unisys.COM (Ken >Leonard) writes: >> Is Ultra (Systems Inc.?) actually shipping working systems? Who is >using one? >> How well does it work? > >We have an Ultra with two frame buffers hooked to our Cray X-MP 48 on an >HSX channel. It works well. Clearly you have a very lightly loaded machine -- on our Y -- which we've only just brought up -- the performance of the Ultra frame buffer is miserable... It is certainly not worth the time and energy that is required to get images up on it. An Abekas digital video recorder is a much better choice, considering the nature of the sort of simulations that one generally does on a Cray. Although standard video resolution is not as good, the fact that one cannot usually render images at the 1024x1280 resolution of the frame buffer, but at something considerably less, say 512^2, I don't see having the resolution of the Ultra frame buffer as a big win. spl (the p stands for pixel pusher) -- Steve Lamont, sciViGuy EMail: spl@ncsc.org NCSC, Box 12732, Research Triangle Park, NC 27709 "Surrealism only comes later when it seems 'reality' becomes difficult to achieve." - E. Miya, NASA Ames Research Center From apollo-request@umix.cc.umich.edu Fri Sep 29 00:06:31 1989 Date: 28 Sep 89 01:21:43 GMT From: steven%moondance%bunyip%metro%basser%usage%ccadfa%csc%munnari.oz.au.uucp@uunet.uu.net (Rm 303 Phone 3973) Subject: backups Message-Id: <1623@moondance.cs.uq.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu At the University of Queensland, we have 7 DN3500 Apollo Workstations (4 of which are disked) running sr10.1 in a bsd environment. We would like to back these up over the network to a remote host (which happens to be a Sun) with a 9 track tape drive. What we are looking for is a backup utility (other than wbak) which will be able to do full and incremental backups of our disks. Apollo's OmniBack product does not allow for the tape host to be a non-Apollo machine and thus is not usefull in this instance. The 'tar | rsh host dd' system does not handle multiple tapes and requires a breakdown of the file system. It also does not cope well with incremental backups since it cannot handle deletions. Does anyone know of, or use a system for backups (commercial or inhouse) that would work well in this type of environment. Thanks in advance. Steven __ Steven Widmayer Asst Systems Programmer University of Queensland. steven@batserver.uq.cs.oz Better to burn out than fade away. From apollo-request@umix.cc.umich.edu Fri Sep 29 00:07:07 1989 Date: 29 Sep 89 02:58:01 GMT From: zeleznik%cs.utah.edu%hellgate.utah.edu%mailrus.uucp@tut.cis.ohio-state.edu (Mike Zeleznik) Organization: University of Utah CS Dept Subject: BSD sockets and blocking in 10.1 Message-Id: <1989Sep28.205528.6220@hellgate.utah.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu SR 10.1, dn10000 or dn3500. I notice that bsd sockets, set in AF_UNIX mode, are non-blocking by default. In AF_INET mode, they are blocking. I thought they both should be blocking. (and I can only see a way to make them NON blocking, not the reverse; with fcntl). Am I off base, or is this a problem? Thanks, Michael Zeleznik Computer Science Dept. University of Utah zeleznik@cs.utah.edu Salt Lake City, UT 84112 (801) 581-5617 From lubkin@apollo.com Fri Sep 29 10:23:57 1989 Message-Id: <8909291447.AA15579@xuucp.ch.apollo.com> From: lubkin@apollo.com Date: Fri, 29 Sep 89 10:41:55 EDT Subject: INFO-DSEE mail To: dsee_list:@apollo.com Date: fri, 29 sep 89 10:27:34 From: conliffe@caen.engin.umich.edu (Darryl C. Conliffe) Subject: Dead group Is the group off line or just dead. Has everyone given up on DSEE and gone to SCCS as a move to "standards"? Am I the only fool out here still using this stuff? If not, can anyone answer these: 1. In a mixed SR 9 and SR 10 system, how many and which sf_helper's are needed (any node will do, or not?)? 2. In a mixed network, where the release has been compiled and bound with SR 9 tools, I have constructed a release with -snapshot containing the compilers, ins files, lib files, and any other tools I need to rebuild the release. The development occurs in SR 9.7 but is tested in SR 10 environments. Can the release be used in the thread to make it possible to rebuild the executable with the tools stored in the release area? How? ====================================================================== Post to info-dsee@apollo.com Administrative mail to info-dsee-request@apollo.com ====================================================================== ------- From apollo-request@umix.cc.umich.edu Fri Sep 29 11:34:00 1989 Date: Fri, 29 Sep 89 08:48:13 CDT From: Andrew M. Wescott Message-Id: <8909291348.AA03631@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu Subject: Sun Tar Tapes on Apollos I know I've heard this discussed out here before, but I never thought it would happen to me! How can I read a Sun Tar tape written with /dev/rst0 on an Apollo node ? My local SE says it can't be done with the device (rst0) chosen by the Sun user that wrote the tape. Using tar tf /dev/rct8 gives "blocksize = 0" . Don't tell me to make friends with our Sun administrators. Thanks, Andrew Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Fri Sep 29 11:48:06 1989 Message-Id: <8909291500.AA06515@umix.cc.umich.edu> Date: 29 Sep 89 09:45:00 CST From: "DAVE ERSTAD" Subject: SR10 Gotcha To: "apollo" Here's a minor SR10 gotcha to be aware of, if you do software development. Someone at Apollo apparently likes the common C paradigm of defining a compiler pre-processor variable in header files, then testing the variable to avoid repeated use of the contents of that file. At SR10, all the /sys/ins/?*.ins.pas files have such a variable. If the same file is included more than once in the same program, the second and subsequent includes are effectively ignored. Of course, this is NOT upward compatible! The scope of compiler variables is not the same as the scope of identifiers in a Pascal program; hence programs which were just fine at SR9.7 may not compile at SR10. Now, this isn't a real big deal - it just took the engineer involved a couple hours to fix the code ONCE he figured out what was going on. And I can see where someone might argue that this is enough of a beneficial change to justify some inconvienence. But it'd sure be nice if the release notes said something. In generl, though, I can't complain too much about migrating to SR10. We've converted about 200,000 lines of code without too much difficulty - 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). Dave Erstad Principal Design Automation Engineer Honeywell SSEC DERSTAD@cim-vax.honeywell.com From lubkin@apollo.com Fri Sep 29 12:50:45 1989 Message-Id: <8909291707.AA16748@xuucp.ch.apollo.com> From: lubkin@apollo.com Date: Fri, 29 Sep 89 12:58:56 EDT Subject: INFO-DSEE mail To: dsee_list:@apollo.com Date: fri, 29 sep 89 13:19:00 From: derstad@cim-vax.honeywell.com ("DAVE ERSTAD") Well, I certainly haven't given up on DSEE. I would have a hard time doing my job without it. We are running mixed SR9 and SR10, and have a single sf_helper. The sf_helper is running on an SR9.7 node. We have a 50-60 node network, with about a dozen nodes using DSEE fairly actively. We have not had any problems. I don't know about the other question. 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 Sep 29 16:10:59 1989 Date: Fri, 29 Sep 89 14:50:12 EDT From: krowitz@richter.MIT.EDU (David Krowitz) Message-Id: <8909291850.AA11498@richter.mit.edu> To: wescott@lnic1.hprc.uh.edu Subject: Re: Sun Tar Tapes on Apollos Cc: apollo@umix.cc.umich.edu I believe the Sun's G (let's start this again) I believe the Suns have two device files, /dev/rst0 and /dev/rst8. The rst0 file writes the old QIC-11 format tapes (which are lower density) and the rst8 device writes the newer QIC-24 format. The Apollo cartridge drives handle QIC-24 tapes only. -- 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 Sep 29 16:11:06 1989 Date: Fri, 29 Sep 89 12:22:11 CDT From: lray@civilgate.ce.uiuc.edu (Ray) Message-Id: <8909291722.AA00609@civilgate.ce.uiuc.edu> To: apollo@umix.cc.umich.edu Subject: Why is /etc/reboot so unreliable? 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. Condition 1 is the most understandable. If there has been a crash and the hardware clock has been scrambled, then it seems clear a sanity check is in order. Condition 2 could be something to do with the ROM level of the cpu. I have not done enough testing to verify when this happens. Condition 3. is the strangest. It acts like the node is in service mode when I know for a fact it is in normal mode (yes, pressing the reset button works as expected). The problem with all this is that I simply cannot easily get access to the offices where there is a node at all times. This means the node stays down for an unacceptably long period of time while I wait for a key to become available. --------------------------------------------------------------------- Does anyone know how /etc/reboot works, enough to give me some insight as to whats going on here? Leland Ray UIUC - CE Dept. (217) 333-3821 From apollo-request@umix.cc.umich.edu Sat Sep 30 01:24:42 1989 Date: 30 Sep 89 02:59:10 GMT From: abair%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Alan Bair) Organization: SPS CAD, Motorola Inc., Austin, Texas. Subject: Re: Sun Tar Tapes on Apollos Message-Id: References: <8909291348.AA03631@lnic1.hprc.uh.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >From what I remember reading here before and trying, you have to use /dev/rst8 on the Sun since the Apollo cartridge drives cannot read the lower density /dev/rst0 format. Alan From apollo-request@umix.cc.umich.edu Sat Sep 30 01:41:12 1989 Date: 30 Sep 89 02:56:13 GMT From: abair%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Alan Bair) Organization: SPS CAD, Motorola Inc., Austin, Texas. Subject: Re: backups Message-Id: References: <1623@moondance.cs.uq.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I know you said you did not want to use wbak, but take a look at the -remote(?) option. With SR10.1, you can run wbak and send the output to the tape on the Sun. I have used it and it works, but I really want it for our DN10000, but its not there yet. Actually before this option was in place, I grabbed a PD verison of a set of rmt routines, the code that does remote tape ops, and made my own little cat to run 'wbak -stdout | rcat ...'. This worked fine to 1/2" tape. I need to get it setup to use our 8mm, then no more tape swapping, even for full backups. Hope you can use this. Actually I would rather use the Unix dump and restore programs, but Apollo does not support them. Alan Bair SPS CAD Motorola, Inc. UUCP cs.utexas.edu!oakhill!turbinia!abair From apollo-request@umix.cc.umich.edu Sat Sep 30 03:55:05 1989 Date: 29 Sep 89 21:38:32 GMT From: reb%quintro%tiamat.uucp@uunet.uu.net (Roger E. Benz) Organization: none Subject: Does anyone know about Computer System Tech Message-Id: <1989Sep29.213832.26124@quintro.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Recently I received a call from Computer Systems Tech wondering if any of their products would be of interest to me. Well after talking to them about their storage systems I became real interested. Their prices for a 100M drive (15ms seek time) and SCSI contreller is $875, a 200M disk is $1795. They also have a 8mm tape drive for $3550 (I don't know about software). My question is: Has anyone delt or heard of these people? Are the products good? Service? ... Any comments would be greatly appreciated. -- 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 Sat Sep 30 05:25:01 1989 Date: 29 Sep 89 21:38:32 GMT From: reb%quintro%tiamat.uucp@uunet.uu.net (Roger E. Benz) Organization: none Subject: Does anyone know about Computer System Tech Message-Id: <1989Sep29.213832.26124@quintro.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Recently I received a call from Computer Systems Tech wondering if any of their products would be of interest to me. Well after talking to them about their storage systems I became real interested. Their prices for a 100M drive (15ms seek time) and SCSI contreller is $875, a 200M disk is $1795. They also have a 8mm tape drive for $3550 (I don't know about software). My question is: Has anyone delt or heard of these people? Are the products good? Service? ... Any comments would be greatly appreciated. -- 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 Sat Sep 30 09:28:58 1989 Date: 29 Sep 89 19:02:44 GMT From: Chuck_SirVAX_Staatse%cup.portal.com%portal.uucp@uunet.uu.net Organization: The Portal System (TM) Subject: Mentor Workstations Message-Id: <22646@cup.portal.com> References: <485@nuts.nu.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We are looking into ASIC development systems. Since there seems to be a high level of expertise on this conference, I would appreciate your inputs/suggestions. The system should be able to 1) Develop ASICs from PLDs thru Custom (gate arrays now) 2) Support at least two workstations which could share data/processing over some network. 3) Support 1.2 u technology. 4) Packages with up to 50K gates and 250 I/O pins. 5) Routing would NOT be done by us. Systems we are currently considering are: VALID, Mentor, Viewlogic. Our consultant is recommending Mentor as the workstation and LSI Logic or VLSI as the gate array source. Although this combination would certainly fit our objective, it is BIG BUCKS! Please send mail here or call me at 609-799-0071 ext. 229 (USA). From apollo-request@umix.cc.umich.edu Sat Sep 30 15:37:06 1989 Date: 28 Sep 89 21:03:38 GMT From: vince%bcsaic%ssc-vax%fluke.uucp@beaver.cs.washington.edu (Vince Skahan) Organization: Boeing Computer Services - Phila. Subject: wierd message from salvol aborting Message-Id: <15319@bcsaic.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Subject: wierd message from aborting salvol in 10.1 Newsgroups: comp.sys.apollo Has anyone seen the following wierd message from an aborted salvol under 10.1 ??? Verifying reference counts Internal error: in read_ahead. Requesting disk block(2716f)that is cached, but is in use or empty. RUN ABORTED ---> the basica situation looks something like this: DN3500 running 10.1.1.1.2 (348 MB disk, 8 MB memory, 19"color) this dude passes all self tests as well as dex tests on memory, winchester, and cpu. Adding the block referenced above to the badspot list and re-salvol'g didn't help. Powering down for a while also didn't help. -- 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...