HECnet

hecnet@lists.dfupdate.se

7 participants
15595 discussions

Sample DCL code for simple client-server task-to-task comms

by jeep＠scshome.net

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

13 years, 2 months

Sample DCL code for simple client-server task-to-task comms

by bqt＠softjar.se

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? 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? Can another open be done on the same SYS$NET, and you can continue exchanging data? Johnny

13 years, 2 months

SIMH for VMS on VAX

by md.benson＠gmail.com

On 17 Jan 2013, at 04:40, Dave McGuire wrote: Yes, that's SIMH running *on* VMS. Binaries are here, currently only for VAX, still working on alpha, feel free to download: ebola::disk$user:[decnet.simh.vax] Note that there's no network support. Network support works on Alpha, but not VAX. Not sure why. I just shut down an instance of RSTS/E v10.1 under SIMH on my VAX 7700. I'm currently booting VMS 7.3. =) I could use these for Integrity, just... well because ;) If someone can get me a compiler kit for Integrity and 'how the ****' instructions I can do it on my zx6000 but I've never compiled anything under VMS. First time for everything I guess :) -- Mark Benson http://DECtec.info Twitter: @DECtecInfo HECnet: STAR69::MARK Online Resource & Mailing List for DEC Enthusiasts.

13 years, 2 months

Sample DCL code for simple client-server task-to-task comms

by sampsa＠mac.com

Thanks for all the help guys - I think I'm pretty close to having all the stuff I need for my little client server project. Sampsa On 17 Jan 2013, at 08:57, G. wrote: On Thu, 17 Jan 2013 02:52:59 +0200, you wrote: OK, figured that out, I have to use an open to access it first. IIRC, your procedure must open SYS$NET, no matter what it will possibly send through it, even if it will not send anything back, because it is the opening of SYS$NET that triggers the dispatching of the DECnet connect-confirm message back from the target node to the originating one. Just try a procedure that does a five minutes wait, but does not open SYS$NET, and you'll see that the network will time out with an error way before five minutes (and your procedure will be stopped). Then simply add the open of SYS$NET before the wait command and you will see that it will work whatever time you chose for the wait, i.e. it will not time out, because the connection will be opened and confirmed both sides and both ways. IIRC it's not even necessary to explicitly send something thru SYS$NET to confirm the connection, just open it. HTH, :) G.

13 years, 2 months

Sample DCL code for simple client-server task-to-task comms

by sampsa＠mac.com

13 years, 2 months

Sample DCL code for simple client-server task-to-task comms

by gerry77＠mail.com

On Thu, 17 Jan 2013 02:52:59 +0200, you wrote: OK, figured that out, I have to use an open to access it first. IIRC, your procedure must open SYS$NET, no matter what it will possibly send through it, even if it will not send anything back, because it is the opening of SYS$NET that triggers the dispatching of the DECnet connect-confirm message back from the target node to the originating one. Just try a procedure that does a five minutes wait, but does not open SYS$NET, and you'll see that the network will time out with an error way before five minutes (and your procedure will be stopped). Then simply add the open of SYS$NET before the wait command and you will see that it will work whatever time you chose for the wait, i.e. it will not time out, because the connection will be opened and confirmed both sides and both ways. IIRC it's not even necessary to explicitly send something thru SYS$NET to confirm the connection, just open it. HTH, :) G.

13 years, 2 months

Brian Hechinger

by form＠pdp-11.org.ru

Dave McGuire wrote: Happy Birthday, Brian! -Dave Happy Birthday!

13 years, 2 months

Brian Hechinger

by b4＠gewt.net

On 17 Jan 2013, at 00:45, Dave McGuire <mcguire at neurotica.com> wrote: Happy Birthday, Brian! -Dave -- Dave McGuire, AK4HZ New Kensington, PA Happy birthday, Brian! If you want a gift I can give you season 2 of LOST on DVD or a 2000s-era Sony Walkman.

13 years, 2 months

SIMH for VMS on VAX

by b4＠gewt.net

On 17 Jan 2013, at 00:44, Dave McGuire <mcguire at neurotica.com> wrote: On 01/17/2013 12:38 AM, Cory Smelosky wrote: It's a zippy little box, but it's not even in the same league as an ES40. ;) How much heat does it output though? :p It only feels like a *small* hair dryer. ;) I don't even think too much about running little 1U machines, though. You'll understand when you come to visit. Yup. From the pictures I've seen, you've got quite a few racks. ;) Speaking of 1Us, I have a 1U sitting on top of your ES40. Quite a size difference! ;) You're gonna love the es40 sitting in the living room waiting patiently for you in the winter. ;! She'll definitely keep a room warm. You get the one with two drive cages, too. Plus! FibreChannel cards! Schweet! When you come to pick her up and do the trade, you can pick if you want any of the PCI cards from my ES40. Several of them I will never use. ;) I do need to devise a better way to keep the hard drives plugged in though...currently have them propped up with screwdrivers...need something to support the full-height drives that predate the ES40. ;) -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years, 2 months

Brian Hechinger

by mcguire＠neurotica.com

Happy Birthday, Brian! -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years, 2 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet