GBOPOLY1@NUSVM.BITNET (fclim) (05/25/89)
Hi,
In a previous posting <8905200415.AA19215@umix.cc.umich.edu>, I ask:
> I need to know how I may send a message via send_alarm to a node
>that is running a program in GPR_$borrow mode. When a process is in that
>mode, the DM on that node is "locked out". On the other hand, send_alarm
>creates a pad via the DM. So there's no way that send_alarm will work.
>Or is there? I am using SR9.7.
Let me rephrase my question. I need to how user.sys_admin, root or
user.locksmith may send a message via send_alarm (or Unix write(1)) to
a node that is running a program in GPR_$borrow mode.
The messages are urgent and therefore, I do not wish to send thro mail.
I need to know how to break thro a window into the node running a GPR_$borrow
mode program like Mentor Graphics' software or local software.
Only lab managers will be doing this (ie sending urgent messages).
Thanx. -- fclim.
fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu
computer centre
singapore polytechnic
dover road
singapore 0513.krowitz@RICHTER.MIT.EDU (David Krowitz) (05/25/89)
I don't believe that you can do what you want with the released system calls (there may be some internal unreleased GPR calls to accomplish what you want, however). The whole purpose of GPR_$BORROW mode was to give the program absolute control over the screen by borrowing the screen from the display manager (which normally has control of the screen and performs the pad/stream operations). About the only thing I can think of, is that you could use the TONE calls to cause the node to beep in a distinctive manner which would alert the user that there was an incomming message. They could then exit their GPR_$BORROW mode program and read the message. We use the QSEND program (available from ADUS) to pop up messages on the screen of another node in our network. If the node is running a program in GPR_$BORROW mode, QSEND will go ahead and put the message up on the screen and cause the node to beep, but the message is not visible until the GPR_$BORROW mode program exits and releases the screen. -- 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)
oj@apollo.COM (Ellis Oliver Jones) (05/27/89)
In article <8905250301.AA25073@umix.cc.umich.edu> GBOPOLY1@NUSVM.BITNET (fclim) writes: >I need to how user.sys_admin, root or >user.locksmith may send a message via send_alarm (or Unix write(1)) to >a node that is running a program in GPR_$borrow mode. Once a process is using the display via GPR in borrow mode, there's No Way for any other process to "break through" and write to the screen. There's no graphical facility similar to the "broadcast" stuff provided by the DEC VMS system for sending messages to serial terminals, regardless of the privilege level of the sender. Sorry. May I suggest some alternatives which might meet your need? (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. (3) Just use the alarm server. The bell still rings, even though you can't see the popup. Train your users to pay attention to random bells. (On my node, my disk chatters when I get an alarm, so I can tell when it's a real alarm and when it's the application program beeping at me.) Leave off the -bell1 option on the alarm server, and it provides different kinds of beep signals, precisely because of this borrow mode problem. (4) Use the tone_$time call (see /sys/ins/tone.ins.pas) to issue an obnoxiously long beep sound, or morse code signals (like the ... - - - ... the alarm server issues when it's about to crash). Sorry I don't have a better answer. /Ollie Jones (speaking for myself, not necessarily for the Apollo Division of the Hewlett-Packard Company, which, btw, is what we're called now.)
oj@apollo.COM (Ellis Oliver Jones) (05/30/89)
In article <8905251341.AA06990@richter.mit.edu> krowitz@RICHTER.MIT.EDU (David Krowitz) writes: >...there may be some internal unreleased GPR >calls to [allow "breakthrough" alarm operations into >borrow-mode displays.] Actually, there aren't any such unreleased calls. /oj
GBOPOLY1@NUSVM.BITNET (fclim) (06/12/89)
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 <control-e>
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.conliffe@caen.engin.umich.edu (Darryl C. Conliffe) (06/13/89)
In article <8906120536.AA14404@umix.cc.umich.edu>, GBOPOLY1@NUSVM.BITNET (fclim) writes: > Hi, [ comments about desire to interrupt borrow mode ] > 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. NO NO NO! Please don't forget that some people DO use borrow mode for a reason, and undesired information appearing at unexpected times on a workstation screen can ruin work, too! Why not just ask vendors to avoid borrow mode when possible? Applications need not use it to cover the screen, and yet they will be well behaved. Besides, I like my vanilla in vanilla wafers, *NOT* my workstation! ;=)
GBOPOLY1@NUSVM.BITNET (fclim) (06/15/89)
>From: conliffe%caen.engin.umich.edu%mailrus.uucp@bbn.com (Darryl C. Coliffe) >Organization: U of M Engineering, Ann Arbor, Mich. >Subject: Re: Processes in GPR_$borrow mode. >Message-Id: <43d0609a.b11a@falcon.engin.umich.edu> >References: <8906120536.AA14404@umix.cc.umich.edu> > >> However, because root overrides all permission modes, when root issue >> a write(1) or wall(1), the message will still get thro. >> > >NO NO NO! Please don't forget that some people DO use borrow mode >for a reason, and undesired information appearing at unexpected times o >a workstation screen can ruin work, too! Yes I agree; breaking in GPR_$borrow mode violates the very idea of Dennis Cottel's gone program which locks the node using GPR_$borrow mode. *However*, please note that I have qualified myself by saying that I need to know how a superuser like root or user.sys_admin may break into the borrow mode. Not every Tom, Dick and Harry should be able to do that. And a supervisor only do it if there's an urgent message need to send via send_alarm. fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513.
conliffe@caen.engin.umich.edu (Darryl C. Conliffe) (06/16/89)
In article <8906150509.AA02550@umix.cc.umich.edu>, GBOPOLY1@NUSVM.BITNET (fclim) writes: > >From: conliffe%caen.engin.umich.edu%mailrus.uucp@bbn.com (Darryl C. Coliffe) > >> However, because root overrides all permission modes, when root issue > >> a write(1) or wall(1), the message will still get thro. > >> > > > >NO NO NO! Please don't forget that some people DO use borrow mode > >for a reason, and undesired information appearing at unexpected times o > >a workstation screen can ruin work, too! > > Yes I agree; breaking in GPR_$borrow mode violates the very idea of > Dennis Cottel's gone program which locks the node using GPR_$borrow mode. > > *However*, please note that I have qualified myself by saying that I need to > know > how a superuser like root or user.sys_admin may break into the borrow mode. > Not every Tom, Dick and Harry should be able to do that. And a supervisor > only do it if there's an urgent message need to send via send_alarm. I reiterate that there is the possibility that such a user may destroy valuable work in progress, and thus should use a phone or walk over to the station. (Just kidding, I *KNOW* you can't do that *ALL* the time ;=). However, if the objective is to signal a very important condition that needs user attention, then a routine that rings the bell of the workstation, obnoxiously and repeatedly until acknowledged may be your answer. BTW, I am not considering Cottel's gone program in the class of "don't interrupt" routines. I think an installation should modify gone to make it interruptable via root and/or sys_admin. It's CAD, visualization, or rendering applications I think should be protected. Vendors could help by not using borrow mode in their designs, but that's a different train of thought. -- ___________________ Darryl C. Conliffe conliffe@caen.engin.umich.edu (313) 721-6069 -------------------