[mod.computers.vax] Broadcast trapping

GKN@SDSC.BITNET (Gerard K. Newman) (11/09/86)

        From:    "Mark Layton" <mark@ntsc-74>
        Subject: Problems with broadcast trapping
        Date:    6 Nov 86 15:11:00 EST


           I've finally given up trying to find an answer to this problem on
        my own. I got tired of having my edit sessions interrupted by users
        sending messages to my terminal (via a program installed with privilege
        to broadcast to other terminals). So I wrote a program , largely lifted
        from the FORTRAN programmer's reference manual, to trap these messages
        and log them to a file. I $SPAWNED a subprocess in my login.com file
        to run this program.  So far, so good. It worked just fine. However,
        some very strange side effects have resulted. If I do a HELP command
        which requires more than one screen to display (FORTRAN for example)
        HELP prints the message "Press return to continue". When I do, I get the
        fatal error message "%RMS-F-USZ, invalid user buffer size" . Also, If
        I attempt to spawn a subprocess, I get the message "%DCL-E-TRMMBX,
        terminal has associated mailbox - terminate image and then spawn".

Please see page DCL-610 of the VAX/VMS DCL Dictionary, where it states that
the SPAWN and ATTACH commands (and hence LIB$SPAWN and LIB$ATTACH) cannot
be used if your terminal has an associated mailbox.  The reason for this is
simple:  if your terminal has an associated mailbox, and there isn't a read
posted to your terminal at all times, then unsolicited data arrival ASTs
can be queued to this associated mailbox (which is probably not what you had
in mind).

        And finally, when I try a SET HOST, I get the message
        "%SYSTEM-F-DEVACTIVE, device is active". If I stop the process which
        is running the broadcast trapper, everything returns to normal.

RTPAD (the program which is run when you type $ Set Host) uses an associated
mailbox, and expects to be able to create it itself.  Your program has already
established one, and hence RTPAD loses.

        As far as I can determine, this is all the fault of the SMG routine
        SMG$SET_BROADCAST_TRAPPING. If I remove the call to this routine from
        my program, everything is fine. Of course,  then there's no point to
        having the program. My guess is that SMG$SET_BROADCAST_TRAPPING
        somehow sets up a mailbox which is attached to the terminal and that
        VMS uses SYS$BRDCST to do lots of stuff which expects to be going to a
        terminal, not a mailbox.

Close:  SMG$SET_BROADCAST_TRAPPING does establish a mailbox and associate it
with your terminal.  SYS$BRDCST is simply a jacket routine for SYS$BRKTHRU,
which uses $QIO to write broadcast messages to whatever terminals it was told
to.  It works just fine with associated mailboxes.

Basically, you can either have a broadcast mailbox, or you can use LIB$SPAWN
and friends.  You can't do both at the same time (sad but true).

gkn

--------------------------------------
Arpa:   GKN@SDSC-SDS
Bitnet: GKN@SDSC
USPS:   Gerard K. Newman
        San Diego Supercomputer Center
        P.O. Box 85608
        San Diego, CA 92138
AT&T:   619.534.5076