Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!NUSVM.BITNET!GBOPOLY1 From: GBOPOLY1@NUSVM.BITNET (fclim) Newsgroups: comp.sys.apollo Subject: Re: Processes in GPR_$borrow mode. Message-ID: <8906120536.AA14404@umix.cc.umich.edu> Date: 12 Jun 89 05:33:43 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 81 X-Unparsable-Date: Mon, 12 Jun 89 13:28:39 SST Hi, I am sorry for opening this topic again. Actually, I have not close it yet. I couldn't write earlier because (1) my mailer conked out. I couldn't mail anyone outside S'pore. (2) I was away for a week. I asked in an earlier posting how a Superuser may send messages, via /com/send_alarm or /bin/write, to a node that is running a process in GPR_$borrow. David Krowitz (krowitz@richter.mit.edu), Dennis Cottel (dennis@peanuts.nosc.mil) and Ellis Oliver Jones (oj%apollo.com@eddie.mit. edu) replied and I summarized their suggestions here. (1) Write a program that will beep the speaker on the remote node indefinitely till the user acknowledge. Ollie gave two other suggestions, <437533e0.d5b2@apollo.COM>, : >(1) build some sort of message facility into your borrow mode > application...have it watch some incoming mailbox or > socket, and display whatever it receives. The problem > here is that it requires programming, and probably requires > modification to the core main loop of your application. > >(2) have a privileged message facility deliver some sort of > signal (or fault, if you want to speak Aegis) to > your application. SIGWINCH might be suitable. You > could put a fault handler in the application, and > display a message (after, perhaps, reading it from a > well-known file). Again, this requires application changes. Thanks for the pointers guys, but ... These ideas may not work. Most of my Apollo users are naive users. They are just going to assume that the (indefintely long) beep to means something is wrong with the machine If they can still do their work, they will just ignore it, even though it's irritating. Otherwise, they will go find help which could be 200 metres away. So, they just ignore it, or power down the node. The users may not be aware of a feature of the application that leave GPR_$borrow temporarily. I have a lecturer who was an engineer who have been using Mentor Graphics at Motorola for 2 to 3 years. I was surprised to find out that he doesn't know about ^e (control-e) that release the screen back to the DM until a carriage return. If he doesn't know, who does? Not all 3rd party software have this facility (of temporarily gpr_$terminate); at least I know most of my students will not add this feature -- it is too much of a bother. Are we to insist that all new software we are evaluating to have this capability before we buy them? How about consistency -- not all are going to use like Mentor? What if the application does not have a fault handler to catch SIGWINCH signals? It's going to kill the application process which could have been processing for the past 3 hours. These 3 hours will be going down the tube if there's no SIGWINCH trap. Again, there is the consistency problem -- must we ensure that all 3rd party softwares catches the SIGWINCH signal? What I had in mind is that of vanilla Unix. When a user logs in, the terminal is his. Init (or is it getty) will do a chown /dev/ttynn userid The user may wish to ignore all messages via % mesg n which in effect does a chmod 600 /dev/ttynn However, because root overrides all permission modes, when root issue a write(1) or wall(1), the message will still get thro. How about putting some of the vanilla back into the DM/GPR ? "Kludge, megakludges to the max!" --- Sonarman First Class, Ronald 'Jonesy' Jones. fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513.