From:	SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 27-MAY-1993 11:10:55.25
To:	EVERHART
CC:	
Subj:	Re: Exec, Spawn, Objects in VMS

From: jeh@cmkrnl.com
X-Newsgroups: comp.sys.dec,comp.os.vms,vmsnet.misc
Subject: Re: Exec, Spawn, Objects in VMS
Message-Id: <1993May26.131430.2072@cmkrnl.com>
Date: 26 May 93 13:14:30 PDT
Organization: Kernel Mode Systems, San Diego, CA
Lines: 60
To: Info-VAX@kl.sri.com
X-Gateway-Source-Info: USENET

In article <1993May25.152103.6262@dbased.nuo.dec.com>,
 winalski@adserv.enet.dec.com (Paul S. Winalski) writes:
> 1) One and only one I/O channel can be opened on SYS$NET:.  All DECnet
>    communications have to take place over that channel.  In particular, a
>    subprocess cannot access its parent's DECnet link.

As some might see a conflict between my and Paul's responses in this thread,
I thought I'd post a clarification:

Paul is correct here.  The reason is that the $ASSIGN channel to SYS$NET is
"special".  The reason it's special is that the equivalence name of SYS$NET is
not just a device name; it's the network connect block that will tell DECnet
which inbound connect request you're confirming.  The channel ends up being
assigned to a pseudo-device called NETnnnn, but that device isn't ready for use
until after the $ASSIGN to SYS$NET has been done, confirming the link.  (It may
not even exist until that $ASSIGN is done, I haven't checked.)

You can also confirm the link by $ASSIGNing to NET0:, which gets you a channel
to a NETnnnn, picking the NCB out of SYS$NET's equivalence name, and passing
the NCB to NETnnnn with a $QIO IO$_ACCESS; this is part of non-transparent
programming.  

You can't assign a second channel to SYS$NET because once you've assigned the
first one, the connect request which SYS$NET describes has already been 
confirmed!  (You might think of SYS$NET has having been "used up".)

Someone is no doubt wondering what happens if you $ASSIGN to SYS$NET, then do a
$GETDVI on the channel to recover the NETnnnn device name, then try to $ASSIGN
a second channel to that device name.  I was, so I tried it.  The second
$ASSIGN will complete without error but the resulting channel can't be used to
talk to the DECNet link, because the WCB pointer in the channel control block
isn't filled in.  I suppose this could be patched up via a little bit of
kernel-mode code.  

All of this is a little afield of the original question.  The questioner wanted
(I think) to have a process (we'll call it the "switcher") declare its name to
DECnet via IO$_ACPCONTROL, receive multiple inbound connect requests (via a
mailbox associated with the channel used to do the ACPCONTROL), and pass them
off to other processes. Such a process CAN pass the NCBs read from the mailbox
to other processes, and let the other processes confirm the links. 

But this doesn't contradict Paul's assertion, as it does not involve multiple
$ASSIGNs to SYS$NET; SYS$NET won't be involved at all in this technique, except
perhaps for the first incoming connect to the "switcher" process (and that
connect cannot be handed off to another process). 

If you want the "switcher" process to confirm the links and read something from
the link to determine what image to run in another process to service the
link.... you can't do that, because it would require assigning two different
channels to the link (one in the "switcher" process and one in the "server"
that it creates).  But you CAN use non-transparent programming to send the
"server selection" information in the Network Connect Block; the "switcher" can
then examine the NCB received in the mailbox message to determine what image to
run in the server, and the server can confirm the link. 

	--- 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