On Wed, 6 Jan 2010 11:50:05 -0500, you wrote:
"Reserved" means "send zero, ignore on receipt". It most definitely
does NOT mean "check on receive that this is zero", that's a silly
mistake all too often make in protocol design. This too is for mixed
version handling. If a new flag can safely be ignored by an older
system, then the newer system can simply send that flag in what used to
be a reserved field, and the right thing happens.
Sure, but I'm not trying to implement something nor to make different DECnet
versions cooperate. I'm just studying the actual content of some packets and
have noticed some discrepancies between the standard specifications and the
actual data on wire, sent from a VMS V7.2 box to another V7.2 system. :-)
Finally, proxy was originally a VMS specific enhancement and was adopted
in some other implementations (I know DECnet/E picked it up, at least in
a semi-compatible form). I'm not sure that it was ever specified in an
architecture spec.
See above. What I'm looking at is the data exchange between two VMS boxes,
both at V7.2, so it's not strange to see something about proxies.
Speaking about specifications, I was thinking that DEC was quite strict
about this and I was hoping that somewhere there was at least an update if
not an entire new specification, or that someone would know who to ask for.
BTW, all the differences I've found are in the session control protocol and
the one about proxies is just one of them: another is in the contents of the
format 2 "destination end user name".
Thanks,
G.
Steve,
As discussed on the list, the problem was with SIMH on Snow Leopard specifically and Johnny seems to have fixed whatever it was. Thanks for the offer though.
Sampsa
On 2 Jan 2010, at 19:46, Steve Davidson wrote:
I use simh all the time. If I can help I will be around most of the weekend.
My only task this weekend is dealing with the snow on the driveway. So far we have had 5+ inches. They expect another 5-7 more. The snow blower went through this last pass in 90 minutes.
-Steve
From: Sampsa Laine [mailto:sampsa at mac.com]
Sent: Sat 1/2/2010 14:31
To: Steve Davidson
Subject: Re: [HECnet] We're (sort of ) back up again.
It's not a VMS issue per se I think - something to do with SIMH and the network interface. I might have a play later.
Sampsa
On 2 Jan 2010, at 19:06, Steve Davidson wrote:
Sampsa,
If you need any help with this - let me know. I'm around all weekend. Most of this time will be spent hacking!!!
-Steve
From: owner-hecnet at Update.UU.SE on behalf of Sampsa Laine
Sent: Sat 1/2/2010 13:16
To: hecnet at Update.UU.SE
Subject: [HECnet] We're (sort of ) back up again.
I've replaced the server that ran my bridge and GORVAX, unfortunately there's something REALLY broken with GORVAX that I just can't figure out right now (and don't really have the time to, either). Anyway, RHESUS and CHIMPY are up, CHIMP should be up RSN. GORVAX will be down for a little while longer, as will the Fidonet mail gateway. Sampsa
That would be very useful, care to elaborate on what the problem was, and/or link me to your fixed source/binaries?
BTW, I've noticed that binaries are wonderfully portable across OS X systems, for example, when I recompiled your bridge on Snow Leopard with the latest Xcode, it kept stack dumping. However the binary compiled on Tiger Server works fine and doesn't have any problems.
Sampsa
On 6 Jan 2010, at 22:56, Johnny Billquist wrote:
Sampsa Laine wrote:
Gentlemen, GORVAX and it's associated MULTINET pipe are up again. There is something about either my new iMac or Snow Leopard that breaks the networking on SIMH, so I've momentarily put it on my (already overloaded) Mac mini. This stops me from using the mini as a media centre however, so I need to find another box for it to run on.
Doh.
Maybe I can help. I just fixed a "problem" or two in simh, which
prevented the networking to work right on my macbook pro with snow leopard.
Contact me off list to investigate this further...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Sampsa Laine wrote:
Gentlemen, GORVAX and it's associated MULTINET pipe are up again. There is something about either my new iMac or Snow Leopard that breaks the networking on SIMH, so I've momentarily put it on my (already overloaded) Mac mini. This stops me from using the mini as a media centre however, so I need to find another box for it to run on.
Doh.
Maybe I can help. I just fixed a "problem" or two in simh, which
prevented the networking to work right on my macbook pro with snow leopard.
Contact me off list to investigate this further...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Gentlemen, GORVAX and it's associated MULTINET pipe are up again. There is something about either my new iMac or Snow Leopard that breaks the networking on SIMH, so I've momentarily put it on my (already overloaded) Mac mini. This stops me from using the mini as a media centre however, so I need to find another box for it to run on.
Sampsa
I'm not having much luck looking for newer ones. It may be possible to
reverse engineer the differences from the implementation source code, if
available. I looked a bit at DECnet/E but it's not easily to parse...
Keep in mind the DECnet version handling and reserved field rules.
When mixed versions communicate, both sides report their version and the
higher version system is then responsible for speaking in a way that the
older system will understand.
"Reserved" means "send zero, ignore on receipt". It most definitely
does NOT mean "check on receive that this is zero", that's a silly
mistake all too often make in protocol design. This too is for mixed
version handling. If a new flag can safely be ignored by an older
system, then the newer system can simply send that flag in what used to
be a reserved field, and the right thing happens.
Finally, proxy was originally a VMS specific enhancement and was adopted
in some other implementations (I know DECnet/E picked it up, at least in
a semi-compatible form). I'm not sure that it was ever specified in an
architecture spec.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of gerry77 at mail.com
Sent: Tuesday, January 05, 2010 8:46 PM
To: hecnet at Update.UU.SE
Subject: [HECnet] DECnet session control specification
Hello everyone!
During the last week or so I've spent many hours studying some DECnet
traffic because I was willing to better understand its inner working.
Well, I've discovered that the session control specification commonly
available on the Internet (V1.0) is not the latest, and it seems that
another newer version is not readily available.
While other DECnet protocols such as DRP and NSP appear to be current
(and
in facts their description matches actual data captured from the
Ethernet),
the SCP is obviously different both in formal definition and in
practice.
For example, the specification states that for V1.0 the version field
should
be 000 binary, but VMS sets it to 001 and a bit field that should be
reserved for future use and always set to zero has actually a meaning
(at
least one bit seems to be used to signal proxy access requests).
So the question is: does anyone here has a copy of a newer session
control
specification or at least knows which are the the differences between
V1.0
and the following (V1.1?) version?
Thank you very much,
G.
Hello everyone!
During the last week or so I've spent many hours studying some DECnet
traffic because I was willing to better understand its inner working.
Well, I've discovered that the session control specification commonly
available on the Internet (V1.0) is not the latest, and it seems that
another newer version is not readily available.
While other DECnet protocols such as DRP and NSP appear to be current (and
in facts their description matches actual data captured from the Ethernet),
the SCP is obviously different both in formal definition and in practice.
For example, the specification states that for V1.0 the version field should
be 000 binary, but VMS sets it to 001 and a bit field that should be
reserved for future use and always set to zero has actually a meaning (at
least one bit seems to be used to signal proxy access requests).
So the question is: does anyone here has a copy of a newer session control
specification or at least knows which are the the differences between V1.0
and the following (V1.1?) version?
Thank you very much,
G.
At 2:26 PM +0000 1/5/10, Mark Wickens wrote:
On Tue, 2010-01-05 at 06:24 -0800, Bob Armstrong wrote:
>Anyway it seems that whenever I run Personal Alpha any Simh machines I
>have running completely pause until I shutdown the Alpha simulator has
>anyone else had this problem ?
Isn't Personal Alpha a version of the Charon-AXP emulator? I've never
used Personal Alpha, but I am using the free version of Charon-AXP and I can
tell you that, unlike simh, it has no OpenVMS idle detection. Charon will
always use 100% of whatever CPU(s) it's running on, regardless of what the
emulated system is doing. That makes it difficult to run Charon
concurrently with other simulators unless you can afford to dedicate
separate CPUs to each one.
Bob
--
... and significantly bumps up your electricity bill to boot.
How does it perform on something like an Atom processor? I've been thinking about building a system with an Atom 330 CPU for SIMH, KLH10 and E11.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
On Tue, 2010-01-05 at 06:24 -0800, Bob Armstrong wrote:
Anyway it seems that whenever I run Personal Alpha any Simh machines I
have running completely pause until I shutdown the Alpha simulator has
anyone else had this problem ?
Isn't Personal Alpha a version of the Charon-AXP emulator? I've never
used Personal Alpha, but I am using the free version of Charon-AXP and I can
tell you that, unlike simh, it has no OpenVMS idle detection. Charon will
always use 100% of whatever CPU(s) it's running on, regardless of what the
emulated system is doing. That makes it difficult to run Charon
concurrently with other simulators unless you can afford to dedicate
separate CPUs to each one.
Bob
--
... and significantly bumps up your electricity bill to boot.
Anyway it seems that whenever I run Personal Alpha any Simh machines I
have running completely pause until I shutdown the Alpha simulator has
anyone else had this problem ?
Isn't Personal Alpha a version of the Charon-AXP emulator? I've never
used Personal Alpha, but I am using the free version of Charon-AXP and I can
tell you that, unlike simh, it has no OpenVMS idle detection. Charon will
always use 100% of whatever CPU(s) it's running on, regardless of what the
emulated system is doing. That makes it difficult to run Charon
concurrently with other simulators unless you can afford to dedicate
separate CPUs to each one.
Bob
