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

[Steve Davidson]

-----Original Message-----
From: owner-hecnet at Update.UU.SE 
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Brian 
Schenkenberger, VAXman-
Sent: Thursday, January 17, 2013 07:17
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Sample DCL code for simple 
client-server task-to-task comms

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.

I do remember one (1) exception to this rule!   It cost me a day of
debugging EDT.   EDT has a callable interface and by itself that was not
necessarily a problem.   However, in this particular case, when the
terminal was (is) opened and EDT is called by a detached process you can
run into a problem.   EDT, until V3.10 missed one of the closes and had
to rely on process rundown.   No one ever new this - it was simply an
oversite.   This poor customer kept increasing the number of files that
could be opened, under process quota until the application crashed.
After each edit session one (1) channel would be still hanging (open).
Debugging a detached program turned out to be quite a challenge.
Fortunately,   Mark Bramhall had run into a issues with TPU and detached
process so he ran his own version of the debugger.   He taught me (in
short order) how his version worked and (again in short order) I was
able to see the problem.   I do not know if they were able to address
that issue within VMS - I moved on after that bug was fixed.

Thanks for the memories!

-Steve

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

Well I speak to machines with the voice of humanity.