HECnet

hecnet@lists.dfupdate.se

4 participants
15588 discussions

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

by sampsa＠mac.com

Have you looked at final status in process accounting??? There's an old adage: Shit happens! Here is my corollary: Shit happens for/with a reason! No - how do I do that? sampsa

12 years, 11 months

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

by system＠TMESIS.COM

sampsa at mac.com writes: $ HELP/MESSAGE LINKABORT > > Perhaps, your python was attacked by a mongoose (unexpected exception)? > Tried that, have rebooted, still not working again? This is so weird, it ran problem free for like 20 hours, then suddenly, boom, gone. Have you looked at final status in process accounting??? There's an old adage: Shit happens! Here is my corollary: Shit happens for/with a reason! -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity.

12 years, 11 months

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

by sampsa＠mac.com

sampsa at mac.com writes: On 17 Jan 2013, at 16:02, Cory Smelosky <b4 at gewt.net> wrote: 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? ;) > - Not per se but the DECNET stack got into a pretty bad state - had to reboot. I've never had to reboot a VMS box for anything DECnet related. Yeah, this is some weird interaction between Python and DECNET TASKs. It refuses to start python, basically. DECNET boxes seem pretty easy to DOS... Poor application programming is not the fault of the system it runs on! ;) A poor application program shouldn't take out the network stack :)

12 years, 11 months

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

by system＠TMESIS.COM

sampsa at mac.com writes: On 17 Jan 2013, at 16:02, Cory Smelosky <b4 at gewt.net> wrote: 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? ;) > - Not per se but the DECNET stack got into a pretty bad state - had to reboot. I've never had to reboot a VMS box for anything DECnet related. DECNET boxes seem pretty easy to DOS... Poor application programming is not the fault of the system it runs on! ;) -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity.

12 years, 11 months

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

by sampsa＠mac.com

$ HELP/MESSAGE LINKABORT Perhaps, your python was attacked by a mongoose (unexpected exception)? Tried that, have rebooted, still not working again? This is so weird, it ran problem free for like 20 hours, then suddenly, boom, gone.

12 years, 11 months

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

by system＠TMESIS.COM

sampsa at mac.com writes: 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? $ HELP/MESSAGE LINKABORT Perhaps, your python was attacked by a mongoose (unexpected exception)? -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity.

12 years, 11 months

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

by sampsa＠mac.com

On 17 Jan 2013, at 16:02, Cory Smelosky <b4 at gewt.net> wrote: 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? ;) - Not per se but the DECNET stack got into a pretty bad state - had to reboot. DECNET boxes seem pretty easy to DOS...

12 years, 11 months

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

by system＠TMESIS.COM

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.

12 years, 11 months

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

by sampsa＠mac.com

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.

12 years, 11 months

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

by b4＠gewt.net

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.

12 years, 11 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet