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

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