[Info-vax] [OpenVMS Alpha V8.3] SET TERM hang

[Richard Maher]

Hi Michael,

"Michael Moroney" <moroney at world.std.spaamtrap.com> wrote in message
news:hejjus$rkp$1 at pcls4.std.com...
> peter at langstoeger.at (Peter 'EPLAN' LANGSTOeGER) writes:
>
> >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.

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