[HECnet] Sample DCL code for simple client-server task-to-task comms

[Brian Schenkenberger, VAXman-]

Johnny Billquist <bqt at softjar.se> writes: 

On 2013-01-17 13:17, Brian Schenkenberger, VAXman- wrote:
sampsa at mac.com writes:

How come writing to SYS$NET doesn't send any output?

FOOBAR.COM is now:

$WRITE SYS$NET "Foobar"
$DIRECTORY/OUTPUT=SYS$NET

But I only get the directory listing.

Before you can WRITE to any device, and SYS$NET is, in essence here, a
device, you must first OPEN a channel to it.   In DCL, the OPEN command
will create the channel and assign the channel to a logical name which
can subsequently be used in the WRITE.   You cannot WRITE to a terminal
or a file without OPENing a channel either, for example:

$ SHOW LOGICAL TT
      "TT" = "_FTA207:" (LNM$PROCESS_TABLE)
$ WRITE TT "Hello World!"
%DCL-W-UNDFIL, file has not been opened by DCL - check logical name
$ OPEN/WRITE MY_TERMINAL TT:
$ WRITE MY_TERMINAL "Hello World!"
Hello World!
$

WRITE will always return with error if the channel has not first been
OPENed.

The /OUTPUT=SYS$NET tells the DIRECTORY command to send its output to
SYS$NET.   Internally, the DIRECTORY command issues an RMS $OPEN before
it issues any RMS $PUT to output the directory's listing.   The channel
is implicitly $CLOSEd as part of image rundown.

Your channel to SYS$NET, since you don't explicitly issue a DCL CLOSE,
will be implicitly CLOSEd as a feature of process rundown.

How does that work when several processes want to open the device? For 
example, in this case, if DCL opened SYS$NET, and then you run DIRECTORY 
with output directed to SYS$NET. Can DIRECTORY be allowed to open the 
device, even though DCL already have it open?

As a lawyer might tell you about your chances at some matter of law: it
depends.

In VMS there are several things that will control your access to device
I/O.   Privileges and Rights WRT to the device; ownership of the device;
and shareability of the device.

If you don't have privilege or access to the device, you can be denied.
If you don't own the device, you can be denied.
If the device cannot be shared, you can not access the device.

Specifically, with SYS$NET, let's look at the example posted yesterday.

Suppose, DEMO.COM is this:

$ SHOW LOGICAL/FULL SYS$NET /OUTPUT=SYS$NET
$ DIRECTORY/OUTPUT=SYS$NET

On the remote system, you'll see the translation of SYS$NET but nothing
more.   Image rundown or an implicit $CLOSE when processing SHOW LOGICAL
will terminate the connection.   There will be no output from DIRECTORY
seen.

However, if you open a DCL channel (supervisor mode), this will allow,
*in effect*,the back-channel to survive the image rundowns because you
are not issuing a $CLOSE for SYS$NET.

$ OPEN/WRITE NET SYS$NET
$ SHOW LOGICAL/FULL NET /OUTPUT=NET
$ SHOW LOGICAL/FULL SYS$NET /OUTPUT=NET
$ DIRECTORY/OUTPUT=NET
$ CLOSE NET



Also, what happens at close. Is the connection terminated when SYS$NET 
is closed, or is the connection still around until the process is 
terminated?

The DECnet connect is terminated when the $CLOSE is executed.   If the
network process hangs around longer, that's all it's doing.   There is
no more change to communicate with it.

$ OPEN/WRITE NET SYS$NET
$ SHOW LOGICAL/FULL NET /OUTPUT=NET
$ SHOW LOGICAL/FULL SYS$NET /OUTPUT=NET
$ DIRECTORY/OUTPUT=NET
$ WRITE NET "''F$getjpi("","MASTER_PID")'"
$ CLOSE NET
$ WRITE NET "Remote network process ID: ''F$getjpi("","MASTER_PID")'"
$ WAIT 10::	! hang out in front of the drug store... ;)

At this point, you can see the remote process on its node using the
'$ SHOW SYSTEM/NETWORK' command.   You might as well '$ STOP/ID" it as
it's doing nothing.


Can another open be done on the same SYS$NET, and you can continue 
exchanging data?

No.   There will not *be* any more back-channel.   DECnet will have torn
it down upon command from the $CLOSE.   *IF* you need to communicate to
the remote for the life of the network process, then you need to keep
the SYS$NET channel alive such as by using '$ OPEN/WRITE NET SYS$NET'.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker       VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.