On Sun, 25 May 2014, Johnny Billquist wrote:
Got bored of copying stuff using (virtual) serial, eh? ;)
Get an M+ system with split I/D space, and use my TCP/IP instead... :-)
If all goes well whenever Dave heads out this way he'll be dropping off some -11s that HOPEFULLY have split I&D.
Johnny
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 2014-05-25 15:57, Cory Smelosky wrote:
On Sun, 25 May 2014, Jean-Yves Bernier wrote:
Well, my system is working 99%, that's not so bad :)
It is working 100%, you just have performance issues...
Besides playing around, which I admin is awfully fun, the reason for
using DECnet was to transfer big files (tens of megabytes). So I am
out of luck for now, but I haven't said my last word.
Got bored of copying stuff using (virtual) serial, eh? ;)
Get an M+ system with split I/D space, and use my TCP/IP instead... :-)
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
On Sun, 25 May 2014, Johnny Billquist wrote:
Yeah. I'm skimming the Manager's guide (which doesn't actually have the
commands. Seriously. There are blank spaces where the command should be)
I think you've found a scan where anything in red turned invisible. There are other scans of the manuals that are better.
Glad good scans exist! ;)
Ahhhhhhh. That makes much more sense, thanks!
It all makes sense, once you know it. :-)
Yup.
Ahhhhhhhh. I was thinking of it in VMS terms.
Hmm. Terminals are not privileged under VMS, I thought. I though it was users who have various privileges.
I was trying to apply user privilege systems to the terminal stuff. Whoops!
Good thing I've not managed to make the console unprivileged. ;)
Yes. If you make it non-privileged, you will not be able to turn it back to privileged again, since that is a privileged command... :-)
Yeah. ;)
However, by default, the system manager account has the password "SYSTEM" if I remember right. And that leaves you logged in with privileges...
Yup!
Also: it's up!
Event type 4.15, Adjacency up
Occurred 25-MAY-14 10:04:39 on node 9.4 (MANDY)
Circuit QNA-0
Adjacent node = 9.1023 (A9RTR)
...that does not however mean it WORKS.
MOIRA::CSMELOSKY$ set host mandy
%SYSTEM-F-PROTOCOL, network protocol error
Johnny
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 2014-05-25 15:54, Cory Smelosky wrote:
On Sun, 25 May 2014, Johnny Billquist wrote:
Why?
I want to use the disk I had the temporary baseline on for other stuff.
No need to waste an entire 520M disk for 20M of networking. ;)
Once you've done the installation, that disk is not needed.
But you could just copy all the files over, preserving the directory structure. Use BRU.
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
On 2014-05-25 15:53, Jean-Yves Bernier wrote:
At 9:26 AM +0200 25/5/14, Johnny Billquist wrote:
You mean "the Hardware address is whatever you set in simh before
starting". CEX will set it to "Physical address" (in DECNET parlance)
which is AA-00-04-00-(1024 x area + node).
Uh... Not really. simh do not actually change the MAC address of the
physical interface.
Of course, simh don't do DECnet. Communication EXecutive does.
Right. But the communication executive does it by programming the ethernet interface, which get down to a command into simh...
The simh interface starts out with 08-00-2B-AA-BB-CC, but that is
changed to AA-00-04-00-01-28 by DECnet when it starts up, at which
point it no longer listens to 08-00-2B-AA-BB-CC. That address is just
kept around as the original hardware address of the simulated network
interface inside simh.
So we have:
Executor node = 10.1 (SHARK)
Physical address = AA-00-04-00-01-28
Line = QNA-0
Hardware address = 08-00-2B-AA-BB-CC
Executor node = 10.2 (SNAKE)
Physical address = AA-00-04-00-02-28
Line = QNA-0
Hardware address = 08-00-2B-AA-BB-CC
We still have the question "when two nodes runs on the same host, is SET
XQ MAC" necessary? In other words, does the "Hardware address" play any
role in DECnet, besides just being kept around?
No role at all.
Since it would be pointless to put the same address, i tried
SET XQ MAC==00:00:01:00:00:01/02, then
Executor node = 10.1 (SHARK)
Physical address = AA-00-04-00-01-28
Line = QNA-0
Hardware address = 00-00-01-00-00-01
Executor node = 10.2 (SNAKE)
Physical address = AA-00-04-00-02-28
Line = QNA-0
Hardware address = 00-00-01-00-00-02
And I see no difference.
Because it won't any difference. :-)
So, a NIC may have different MAC addresses depending of the network
stack running. Am I right here?
Sortof. Your machine normally do only have one MAC address, but if you
have DECnet running, it will need to change your MAC address. All
other network protocols on your machine will then also use this "new"
MAC address.
If we would run on bare metal. They don't because simh shields it. Maybe
the "Physical address" is kept just for restoring it at shutdown?
Not even that. The physical address is in a PROM on the ethernet card. Any resetting of the bus, and the ethernet card reverts to the address stored in the PROM. (Or whatever you set it to, if we talk about simh.)
Well, my system is working 99%, that's not so bad :)
It is working 100%, you just have performance issues...
Besides playing around, which I admin is awfully fun, the reason for
using DECnet was to transfer big files (tens of megabytes). So I am out
of luck for now, but I haven't said my last word.
Like I said before. I would start by examining various counters on the machines to get more understanding of what the problem is, and then try to solve it from there.
I know that different network interface speeds mess things up, for example, and I have code in my bridge to help get around the problem if the bridge is sitting between the systems.
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
On 2014-05-25 15:53, Cory Smelosky wrote:
On Sun, 25 May 2014, Johnny Billquist wrote:
Heh... Well, you need to know the protection system in RSX...
Yeah. I'm skimming the Manager's guide (which doesn't actually have the
commands. Seriously. There are blank spaces where the command should be)
I think you've found a scan where anything in red turned invisible. There are other scans of the manuals that are better.
File protection is totally unrelated to the terminal privilege status.
File protection comes in four categories.
System - Any access from a group <=10 (octal)
Owner - Should be obvious
Group - Matching group but not member
World - Everybody else
So, in your case, either having a UIC of [131,54] or any system UIC
should have done it. Maybe any member of 131 as well.
[137,10] means you'll fall under the WORLD mask.
Ahhhhhhh. That makes much more sense, thanks!
It all makes sense, once you know it. :-)
The terminal privilege status on the other hand allows you to change
your terminal UIC to anything you want. If you are unprivileged, you
cannot change your UIC.
Ahhhhhhhh. I was thinking of it in VMS terms.
Hmm. Terminals are not privileged under VMS, I thought. I though it was users who have various privileges.
And then, of course, tasks can be installed to run under another UIC
than your terminal UIC...
But installing tasks also requires that your terminal is privileged...
Good thing I've not managed to make the console unprivileged. ;)
Yes. If you make it non-privileged, you will not be able to turn it back to privileged again, since that is a privileged command... :-)
However, by default, the system manager account has the password "SYSTEM" if I remember right. And that leaves you logged in with privileges...
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
On Sun, 25 May 2014, Jean-Yves Bernier wrote:
Well, my system is working 99%, that's not so bad :)
It is working 100%, you just have performance issues...
Besides playing around, which I admin is awfully fun, the reason for using DECnet was to transfer big files (tens of megabytes). So I am out of luck for now, but I haven't said my last word.
Got bored of copying stuff using (virtual) serial, eh? ;)
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Sun, 25 May 2014, Johnny Billquist wrote:
Yeah. I followed the install manual. Thought I configured it for an RA81.
The type of size of the disk don't matter. When you restore the tape image to disk, it will use the same parameters as the original disk the back was created from, unless you explicitly override it. And the disk that the installation tape is created from have very few headers, so that a restore is pretty much ensured to succeed no matter what the destination disk might be...
Whoops. By configured I meant to say "defined MAX and HEADERS".
Anyway, yes, what you should have done is specify a non-default for
maximum number of file headers when you restored the original system
to disk using the BRUSYS system.
I THINK I did that...but I was doing so many different installs in SIMH
the past few days I could've been thinking of another one.
Suspect you missed it in the end.
Yeah, I have to have.
Anyways, dropped to BRUSYS and copied from DU0 to DU1 in SIMH and had
everything copied in 30 seconds. Booting MVII cluster node to copy the
new image as we speak.
Good.
Looks like the VAX finished copying the image. Shutting it down now.
Johnny
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Sun, 25 May 2014, Johnny Billquist wrote:
Why?
I want to use the disk I had the temporary baseline on for other stuff. No need to waste an entire 520M disk for 20M of networking. ;)
Johnny
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
At 9:26 AM +0200 25/5/14, Johnny Billquist wrote:
You mean "the Hardware address is whatever you set in simh before
starting". CEX will set it to "Physical address" (in DECNET parlance)
which is AA-00-04-00-(1024 x area + node).
Uh... Not really. simh do not actually change the MAC address of the physical interface.
Of course, simh don't do DECnet. Communication EXecutive does.
The simh interface starts out with 08-00-2B-AA-BB-CC, but that is changed to AA-00-04-00-01-28 by DECnet when it starts up, at which point it no longer listens to 08-00-2B-AA-BB-CC. That address is just kept around as the original hardware address of the simulated network interface inside simh.
So we have:
Executor node = 10.1 (SHARK)
Physical address = AA-00-04-00-01-28
Line = QNA-0
Hardware address = 08-00-2B-AA-BB-CC
Executor node = 10.2 (SNAKE)
Physical address = AA-00-04-00-02-28
Line = QNA-0
Hardware address = 08-00-2B-AA-BB-CC
We still have the question "when two nodes runs on the same host, is SET XQ MAC" necessary? In other words, does the "Hardware address" play any role in DECnet, besides just being kept around?
Since it would be pointless to put the same address, i tried
SET XQ MAC==00:00:01:00:00:01/02, then
Executor node = 10.1 (SHARK)
Physical address = AA-00-04-00-01-28
Line = QNA-0
Hardware address = 00-00-01-00-00-01
Executor node = 10.2 (SNAKE)
Physical address = AA-00-04-00-02-28
Line = QNA-0
Hardware address = 00-00-01-00-00-02
And I see no difference.
So, a NIC may have different MAC addresses depending of the network
stack running. Am I right here?
Sortof. Your machine normally do only have one MAC address, but if you have DECnet running, it will need to change your MAC address. All other network protocols on your machine will then also use this "new" MAC address.
If we would run on bare metal. They don't because simh shields it. Maybe the "Physical address" is kept just for restoring it at shutdown?
Well, my system is working 99%, that's not so bad :)
It is working 100%, you just have performance issues...
Besides playing around, which I admin is awfully fun, the reason for using DECnet was to transfer big files (tens of megabytes). So I am out of luck for now, but I haven't said my last word.
--
Jean-Yves Bernier
