Conference noted::hackers_v1

    You make it sound as though there will be at least one image rundown
    between the first QIO and later ones; that is, as though you want
    the mailbox to hang around for the life of your process.  If this
    is the case, I'm afraid you're out of luck, unless you want to do
    some hacking to assign the channel (and do QIOs) from a higher
    access-mode than USER.  This will require privileges, or an installed
    image, to accomplish.
    
    If all of your activity is going to take place during the span of
    a single image activation, well, I'm afraid that hanging on to pointers
    to your allocated resources is part of writing modular code.  Silly,
    I know..  I suggest that you read the relevant sections of the Guide
    to Writing Modular Procedures on VAX/VMS; there are several excellent
    suggestions there that may be helpful.
    
    In any event, calling $CREMBX for a pre-existing mailbox is not
    very expensive; certainly vastly less so than opening an existing
    file using RMS, so you're correct there.  As an off-the-top-of-my-head
    guess, I would expect something like a 100:15:1 (or greater) ratio
    for first-creation:$CREMBX-to-existing-mailbox:keeping-channel
    overhead.  Please bear in mind that this is without recoursing to
    the �fiche to verify actions taken in each case.  The ratios are
    probably greater than above, which I feel is best-case.  `No guarantees
    are expressed or implied' - your mileage may vary.
    
    #ken	:-)}

    Of course, if you are in fact doing an image activation/deactivation
    in between steps, then it really doesn't make much of a difference,
    you'll spend much more time getting into the image than either opening
    a file, calling $CREMBX, or calling $TRNLNM.  
    
    BTW: If you are running a new image, then calling $CREMBX is usually
    what's done to get the channel number of the mailbox.  If you are
    doing this completely in DCL (except for the $CREMBX at login time),
    then what you probably want to do after running the program that
    does the $CREMBX is to do a DCL OPEN command -- the channel id will
    remain in the logical you specify and DCL WRITE's and READ's will
    do the trick.

RE: .2

>    If you are
>    doing this completely in DCL (except for the $CREMBX at login time),
>    then what you probably want to do after running the program that
>    does the $CREMBX is to do a DCL OPEN command -- the channel id will
>    remain in the logical you specify and DCL WRITE's and READ's will
>    do the trick.

Unfortunately, this won't work.  The $CREMBX results in a channel that's
assigned in user mode.  It gets run down along with all other user mode stuff
when the program exits.  Unless somebody else has a channel assigned to the
mailbox, the mailbox itself will go away when the channel does at image
exit.  The logical name with the device name (NOT the channel number, mind you)
goes away as well.  The DCL OPEN will fail.

--PSW

RE: .0

You can't remember the channel number, anyway--the channel is deassigned when
the program that did the $CREMBX exits.  $CREMBX does give you the option of
having it create a logical name that translates to the mailbox's device name.
You can use this logical name in subsequent $ASSIGN statements to get new
I/O channels--you don't have to do another $CREMBX.  $ASSIGN is fast.

You mention global sections.  If speed is really important here, why not pass
the messages in a global section and avoid doing $QIO entirely?

--PSW

    You can remember the channel number if it wasn't assigned in user
    mode.  It's not that the mailbox channel is deassigned when the
    image exits, it's that *all* USER-mode activities (logical names,
    channels, exit handlers, and so forth) are run down when the image
    is.
    
    The point about using $ASSIGN is good - if the $ASSIGN call fails,
    the mailbox isn't around, so turn it into a $CREMBX and re-issue
    it.
    
    #ken	:-)}