From:	MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX"  8-JUN-1992 09:45:40.54
To:	info-vax@kl.sri.com
CC:	
Subj:	Re: DCL Mailboxes

In article <1992Jun3.172349.22877@e2big.mko.dec.com>,
 winalski@tle.enet.dec.com (Paul S. Winalski) writes:
> 
> In article <1992Jun2.185019.1@woods.ulowell.edu>,
> sabotkap@woods.ulowell.edu (Pete Sabotka) writes:
> 
> |>Does anyone know of a way to create/manipulate vms mailboxes for use from 
> |>DCL command procedures?  I have heard of several "hacks" to create
> |>mailboxes via DCL, but I would rather find a legitamate way to go about this
> |>(like somehow callin the $CREMBX system service to do it for me). 
> 
> There is no direct access to $CREMBX from DCL.  Somewhere along the way you
> have to write a .EXE to do the $CREMBX for you.  The tricky part then is to
> get the mailbox to stay around after the .EXE exits--you need a channel
> assigned to it in either supervisor mode or exec mode. 

Nah.  Just use the prmflg arg to $CREMBX to make it a permanent mailbox. 

However, for the purpose of creating a mailbox to be used from DCL, I like your
idea better.  It isn't all that hard -- $CMEXEC, then $DCLAST to queue yourself
a supervisor-mode AST, then (from supervisor mode) $ASSIGN a channel.  When
you exit the image the channel remains assigned and the mailbox stays around
(since its reference count is nonzero).  

The advantage of this over a "regular" permanent mailbox is that the latter
requires an explicit $DELMBX call to make it go away, whereas a temporary
mailbox that is "permanent" by virtue of a supv-mode channel will automatically
go away when you log out.  The extra channel won't bother anything. 

Why bother dropping to supv mode? Why not just $ASSIGN the channel from exec
mode?  The latter would work (and would still provide the auto-delete feature).
But as a general principle, I try to do everything from the outermost mode
possible.  

EIther approach requires privilege -- the prmflg requires PRMMBX (a "devour"
privilege), while calling $CMEXEC of course requires CMEXEC.  J. Random User
is more likely to have access to PRMMBX than to CMEXEC.

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru, VMSnet (DECUS uucp) Working Group, and
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh