[OpenVMS Alpha V8.3] SET TERM hang
Peter 'EPLAN' LANGSTOeGER
observed, but didn't know if this is bad and something to become fixed
or is a simple fact (now) and I have to live with it (now).
$ SET TERMINAL/PERM/BROAD OPA0:
sets the OPA0: device to /Broadcast.
But if someone is logged into OPA0:, then this command needs the SHARE
privilege (which all mgrs have) and I/O on OPA0: terminal. That means,
if the user on OPA0: is only logged in, but does nothing, then above
SET TERMINAL (in my SYSHUTDWN.COM) never completes (until someone simply
presses return on OPA0:).
Is this something to be expected (or will it get fixed)?
(I don't remember having seen this problem in 80/90 at all)
I can workaround (like logging out the user on OPA0 or removing the
SET TERM or organizational things) but like to have a permanent solution.
Any comments?
--
Peter "EPLAN" LANGST�GER
Network and OpenVMS system specialist
E-mail Pe...@LANGSTOeGER.at
A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist
David B Sneddon
How about
$ define sys$command opa0:
$ reply/enable
$ deassign sys$command
Dave
Peter 'EPLAN' LANGSTOeGER
>What are you trying to achieve?
To see shutdown messages (and errors) in Console Manager (VCS => PCM => ?)
I only wanted to ensure, that OPA0: doesn't surpress error messages,
because one did a SET TERM/NOBROADCAST in his LOGIN.COM or similar.
This line of code is umpteen years old (and makes me problems once a year
or less for some years now). I removed it now...
>How about
>
>$ define sys$command opa0:
>$ reply/enable
>$ deassign sys$command
Sorry, no cigar.
OPA0: *is* enabled as operator termlnal, but terminal device OPA0: is
eventually /NOBROADCAST and then all broadcasts (incl OPCOM) are blocked...
Michael Moroney
>A shutdown today which didn't complete, reminded me of a behaviour I
>observed, but didn't know if this is bad and something to become fixed
>or is a simple fact (now) and I have to live with it (now).
>$ SET TERMINAL/PERM/BROAD OPA0:
>sets the OPA0: device to /Broadcast.
>But if someone is logged into OPA0:, then this command needs the SHARE
>privilege (which all mgrs have) and I/O on OPA0: terminal. That means,
>if the user on OPA0: is only logged in, but does nothing, then above
>SET TERMINAL (in my SYSHUTDWN.COM) never completes (until someone simply
>presses return on OPA0:).
>Is this something to be expected (or will it get fixed)?
>(I don't remember having seen this problem in 80/90 at all)
>I can workaround (like logging out the user on OPA0 or removing the
>SET TERM or organizational things) but like to have a permanent solution.
>Any comments?
QIO stands for Queued Input/Output. Many I/Os have to wait until other
ones complete. I believe that any SETMODE (SET TERM) on a terminal (any
terminal, not jist OPA0:) has to wait for any READs to complete. There is
a READ at the DCL prompt where DCL is waiting for a commend. I bet the
SET TERM request completes immediately if someone walks up to OPA0: and
presses RETURN.
Richard Maher
"Michael Moroney" <mor...@world.std.spaamtrap.com> wrote in message
news:hejjus$rkp$1...@pcls4.std.com...
If that's the case would a $SET TERM followed by broadcast to that terminal
(which should interrupt the read and give it ss$_opincompl) achieve the
desired results? Perhaps io$_setmode has a breakthru modifier for that
matter?
Regards Richard Maher
JF Mezei
> If that's the case would a $SET TERM followed by broadcast to that terminal
> (which should interrupt the read and give it ss$_opincompl) achieve the
> desired results?
Or better
$SPAWN/NOWAIT SET TERM OPA0:/mumble
$REPLY/TERM=OPA0: "Abracadabra, unlock yourself"
Richard Maher
"JF Mezei" <jfmezei...@vaxination.ca> wrote in message
news:0089753f$0$23360$c3e...@news.astraweb.com...
Could be a chicken&egg senario with the "I can't get it to enable
broadcasts" and "then send it a broadcast message" :-)
Regards Richard Maher
Michael Moroney
>Hi Michael,
>"Michael Moroney" <mor...@world.std.spaamtrap.com> wrote in message
>news:hejjus$rkp$1...@pcls4.std.com...
>> QIO stands for Queued Input/Output. Many I/Os have to wait until other
>> ones complete. I believe that any SETMODE (SET TERM) on a terminal (any
>> terminal, not jist OPA0:) has to wait for any READs to complete. There is
>> a READ at the DCL prompt where DCL is waiting for a commend. I bet the
>> SET TERM request completes immediately if someone walks up to OPA0: and
>> presses RETURN.
>If that's the case would a $SET TERM followed by broadcast to that terminal
>(which should interrupt the read and give it ss$_opincompl) achieve the
>desired results? Perhaps io$_setmode has a breakthru modifier for that
>matter?
I can't tell you for sure. I do know the breakthru modifier (used by
REPLY writes, I'm sure) is kind of funky. Who knows, perhaps it does
work on setmodes, maybe someone can try it! I'm quite sure it's not
documented as applying to setmodes...