From:	MERC::"uunet!WKUVX1.BITNET!MacroMan"  3-APR-1993 14:59:09.54
To:	MACRO32@WKUVX1.BITNET
CC:	
Subj:	Re: Trapping OPCOM messages in Detached proc

In article <1993Apr2.221620.1384@dmc.com>, munroe@dmc.com (Dick Munroe) writes:
> In article <1993Mar23.212708.1640@cmkrnl.com>, jeh@cmkrnl.com writes:
>> The key is VMS's pseudoterminal driver.  (I/O User's Reference Manual, Part
 I,
>> Chapter 9 or so.)  Create a pseudoterminal, associate a mailbox with it,
 enable
>> it as an opcom terminal ($SNDOPR system service), set it for nobroadcast and
>> broadcast mailbox ($QIOW SETMODE).
>
> Presumably you CLEAR nobroadcast and SET broadcast mailbox.

No, I really did mean to SET nobroadcast (this does not inhibit would-be
broadcast messages from going to the associated mailbox, if _BRDCATMBX is set).

> I'm trying to get this to work

No, you're not, you're doing something else.  Says so right here:

        > and am having some luck, but not
        > complete success.  The process I'm going through is:
        >
        > 1. Create a mailbox and get a channel.
        > 2. Create a pseudo terminal and get a channel.
        > 3. Assign a channel to the pt, associating the mailbox.
>>>>>>  > 4. using the channel acquired in 3, clear nobroadcast and set
        > broadcast mailbox.
        > 5. Issue a qio to the mailbox, with an ast set.
        > 6. Enable the pt as an operator device.

> In the ast:
>
> 1. Read the mailbox.
> 2. Issue a queue to the mailbox, with an ast set.
>
> After 6, the AST triggers I see the "...device QUICK$FTA..."
> enabled message from opcom (since I enabled the pt as a central,
> disk, and tape operator I should).  I then cause another OPCOM
> message to be issued (it is issued to the correct operator class
> because another terminal with the same classes enabled sees it)
> and the code just sits there.  The ast never triggers.

Yep - this is what happens if you don't set _NOBRDCST.

Go back and change the code to set the nobroadcast bit, the way i originally
told you (I DID mention that I had working code that did this, didn't I?),
and try it again.

Oh, one other point:  The channel you get from PTD$CREATE shouldn't be used
(at least according to the doc) for doing the $QIO SETMODE.  You need to
use $GETDVI to get the device name, then assign another channel to the same
device (with the assoc'd mailbox), and use THAT channel in your $QIO calls.
Sounds like you're already doing this, but just in case...

        --- Jamie Hanrahan, Kernel Mode Systems, San Diego CA
drivers, internals, networks, applications, and training for VMS and Windows NT
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and
Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG
Internet:  jeh@cmkrnl.com  Uucp: uunet!cmkrnl!jeh  CIS: 74140,2055