Hmm. I haven't tried the bridge on MacOSX myself. Maybe I should. Not nice with crashes.
If you were running some Unix, I would have a simple test for you to check if the problems were as I observed, but with VMS I don't have a good suggestion for a tool to test it.
What I observed (running 2.11BSD on simh here) was that the ethernet input was buffering a whole bunch of packets before delivering them to the emulator. Running ping, I could observe that about 30 packets were sent before I got any replies, and then I got all 30 replies at once. The VMS ping command only sends four pings, so that can probably not be used to test this.
Another problem with simh is that the DEUNA/DELUA emulation is slightly wrong. But I don't know if you are running an 11/780 or a 3900, but I suspect a 3900 in which case that bug wont bite you.
Looking from the outside with tcpdump (or similar program) things do look right. You can see traffic coming out, and replies going back in, but the emulated system don't seem to be receiving.
Sounds like your problem?
Johnny
Sampsa Laine wrote:
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
--
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
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.
Sure. Actually, proxies did get implemented in a number of places, so
you might see it even cross-platform.
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.
DEC was fairly strict, indeed. Sometimes things did get implemented
that weren't well documented. Also, some sections of DECnet were much
more platform-dependent than others, by design. Session Control is an
example, and the old network terminal protocols even more so. By
contrast, things like NSP and, especially, the routing layer were much
more rigidly controlled.
I'm pretty sure there was a Session 1.1 spec. For that matter, there
were (of course) Phase V specs. The problem is that none of these seem
to have been preserved. The specs we do have are on-line because Matt
had the foresight to put them online way back when, and that stuck.
Various other specs were published, or were supposed to be published,
but that doesn't mean they are online. I suspect there are some paper
specs that could be scanned, if someone wanted to do the work.
Then there are some cases where the intent was to publish the specs --
Phase V, Phase IV+ (which is where Session 1.1 might show up) -- but I
know of no evidence that this intent was ever carried out. For example,
I've never seen any trace of the Phase V specs.
Maybe some former DEC person has copies of these documents tucked away
somewhere. If so, one might hope that those could be found, in which
case they can be put online. (Permission was already given to do that
-- permission is NOT the issue in this case.)
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".
The names in format 1 and format 2 destination descriptors are one
example of something that was explicitly left as platform dependent.
For example, I think in VMS and RSX it is a program name, but in RSTS
(DECnet/E) it's something quite different that doesn't tie directly to a
program name at all.
paul
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/ |
