sampsa at mac.com writes:
Strangely enough, the procedures were working fine for almost the whole
day but now I am getting nothing - no errors, just no connections.
What could cause this?
Care to share the "procedures?"
Google NETSERVER$TIMEOUT. I DO NOT recommend you set logical globally as
it will affect *all* DECnet type tasks. You could, if you segregate your
procedure in a group, for example, be defined in a group table. Per job
might be a little trickier than you're ready to tackle.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Basically I just want some code that I can use to wrap some python code around, I was using this:
$@python_vms:setup
$Open/Read/Write net Sys$Net
$DEFINE/NOLOG SYS$OUTPUT net
$DEFINE/NOLOG SYS$COMMAND net
$DEFINE/NOLOG SYS$INPUT net
$python himproto.py
$close net
And it was working all day - suddenly I got Link aborted errors and now nothing. Any ideas?
sampsa
On 17 Jan 2013, at 15:50, sampsa at mac.com wrote:
Strangely enough, the procedures were working fine for almost the whole day but now I am getting nothing - no errors, just no connections.
What could cause this?
sampsa
On 17 Jan 2013, at 09:12, Sampsa Laine <sampsa at mac.com> wrote:
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.
On 17 Jan 2013, at 08:50, sampsa at mac.com wrote:
Strangely enough, the procedures were working fine for almost the whole day but now I am getting nothing - no errors, just no connections.
What could cause this?
Did the target node crash? ;)
sampsa
On 17 Jan 2013, at 09:12, Sampsa Laine <sampsa at mac.com> wrote:
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.
Strangely enough, the procedures were working fine for almost the whole day but now I am getting nothing - no errors, just no connections.
What could cause this?
sampsa
On 17 Jan 2013, at 09:12, Sampsa Laine <sampsa at mac.com> wrote:
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.
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.
Hi Johnny,
My name is John Reinhardt. Long time HECnet lurker, occasional poster and first time requester here. I'm about actually ready to put some systems up and I'd like to request a HECnet area to use. Anything that is free is fine, I don't have any special number desires.
I'm still working out how I will connect. I'm playing with the virtual Cisco that Ian posted recently. Otherwise I may take a shot at the bridge and see if I can get it running on my Vyatta firewall/router.
Where is the latest version of the bridge code?
Regards,
John H. Reinhardt
-----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.
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
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.
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.
