Brief summary: I want to connect a bunch of console cables to a DS200, and server them out using LAT.
I've started LAT on KUHAVX (same LAN segment) but can't see the port I've defined (with a name GVXCON and ACCESS=REMOTE) on the DS200.
The DS200 port config looks like this at the moment:
---- SNIP ---
Local> show port 2
Port 2: Server: HILADS
Character Size: 8 Input Speed: 9600
Flow Control: XON Output Speed: 9600
Parity: None Modem Control: Disabled
Access: Remote Local Switch: None
Backwards Switch: None Name: GVXCON
Break: Disabled Session Limit: 4
Forwards Switch: None Type: Soft
Preferred Service: None
Authorized Groups: 0
(Current) Groups: 0
Enabled Characteristics:
Autoprompt, Broadcast, DSRlogout, Inactivity Logout,
Input Flow Control, Loss Notification, Message Codes,
Output Flow Control, Verification
---- SNIP ---
However on KUHAVX LATCP SHOW SERVICES shows this:
--- SNIP ---
LATCP> show services
LAT Control Program
Service Name Status Identification
---------------- ----------- -------------------------------------------------
KUHAVX Available @SYS$MANAGER:ANNOUNCE.TXT
--- SNIP ---
What am I doing wrong? What commands do I need to type into the DS200 to make it serve out the ports over LAT?
sampsa
Thanks guys. Glad to be a part of it all.
Tim.
Sent from my Sony Ericsson Xperia arc
Peter Coghlan <HECNET at beyondthepale.ie> wrote:
Ah welcome to the fun :)
I'll run a node database update later once they're added.
I see we have 21 areas active in recent days. Is this the most ever?
I've never seen more than 20 in the time I've been here.
Regards,
Peter Coghlan.
Ah welcome to the fun :)
I'll run a node database update later once they're added.
I see we have 21 areas active in recent days. Is this the most ever?
I've never seen more than 20 in the time I've been here.
Regards,
Peter Coghlan.
Ah welcome to the fun :)
I'll run a node database update later once they're added.
Sampsa
On 20 Dec 2012, at 14:12, Tim Sneddon <tim at sneddon.id.au> wrote:
That would be me :-) I just joined!
I have three nodes,
o. DOCMST 12.1 - Ubuntu
o. BENDER 12.2 - VMS, DECnet OSI
o. TRON 12.3 - RSTS 10.1, DECnet/E
Tim.
Sent from my Sony Ericsson Xperia arc
sampsa at mac.com wrote:
Just did my usual SHOW KNOW CIRC on gorvax, and saw an area 12?
They don't seem to be listed in the node database or MIM::DECNET.TXT..
sampsa
That would be me :-) I just joined!
I have three nodes,
o. DOCMST 12.1 - Ubuntu
o. BENDER 12.2 - VMS, DECnet OSI
o. TRON 12.3 - RSTS 10.1, DECnet/E
Tim.
Sent from my Sony Ericsson Xperia arc
sampsa at mac.com wrote:
Just did my usual SHOW KNOW CIRC on gorvax, and saw an area 12?
They don't seem to be listed in the node database or MIM::DECNET.TXT..
sampsa
On 2012-12-20 13:02, sampsa at mac.com wrote:
Just did my usual SHOW KNOW CIRC on gorvax, and saw an area 12?
They don't seem to be listed in the node database or MIM::DECNET.TXT..
Thanks. A typing error on my part. I had missed getting the "2" in there, so Tim Sneddon was claimed to be holding area 1. Fixed now.
Tim, how about giving me a list of node names now?
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 Dec 19, 2012, at 1:08 PM, Johnny Billquist wrote:
On 2012-12-19 17:38, Paul_Koning at Dell.com wrote:
On Dec 19, 2012, at 7:08 AM, Johnny Billquist wrote:
On 2012-12-19 03:27, Clem Cole wrote:
The page size on the VAX is 512 bytes and it lacked COW (copy-on-write)
HW (long, long story as to why, which I will not try to repeat). In
the end, this would be a huge problem with all VAX OSses and HW - take
look any of the sources.
[...]
Well, what it lacks (and I'm sure you know this) is really a modified bit in the page table.
However, it's extremely easy to implement it, and the cost is acceptable, I guess. You just keep the page read-only, and get a trap when someone wants to write. At that time you change the protection, and mark it as modified. There are even a couple of bits in the page entry that are reserved for software use, and you can just decide that one of them is your modified bit.
This is what we do in NetBSD/vax.
I can't imagine any other way of doing it. A copy on write page has to start out read-only, then when the write occurs the write has to be rejected so the copy can be done first. The "trap, copy, and write-enable" approach is the common one; for example, MIPS works exactly this way.
Well, I was talking about implementing the MODIFY bit here, but yes, copy-on-write is an extension to this. However, I pretty much am sure that you cannot do it any easier to cheaper with copy-on-write. The MODIFY bit, though, is something most MMUs have in hardware - not so for the VAX. :-(
That becomes important when you want to know if a page is dirty or not...
Good point.
MIPS is an example of an MMU that doesn't have a modified bit. It has a bit named "dirty" in the page entry, but that's a misleading name -- it is in reality the write-enable bit.
paul
On 2012-12-19 17:38, Paul_Koning at Dell.com wrote:
On Dec 19, 2012, at 7:08 AM, Johnny Billquist wrote:
On 2012-12-19 03:27, Clem Cole wrote:
The page size on the VAX is 512 bytes and it lacked COW (copy-on-write)
HW (long, long story as to why, which I will not try to repeat). In
the end, this would be a huge problem with all VAX OSses and HW - take
look any of the sources.
[...]
Well, what it lacks (and I'm sure you know this) is really a modified bit in the page table.
However, it's extremely easy to implement it, and the cost is acceptable, I guess. You just keep the page read-only, and get a trap when someone wants to write. At that time you change the protection, and mark it as modified. There are even a couple of bits in the page entry that are reserved for software use, and you can just decide that one of them is your modified bit.
This is what we do in NetBSD/vax.
I can't imagine any other way of doing it. A copy on write page has to start out read-only, then when the write occurs the write has to be rejected so the copy can be done first. The "trap, copy, and write-enable" approach is the common one; for example, MIPS works exactly this way.
Well, I was talking about implementing the MODIFY bit here, but yes, copy-on-write is an extension to this. However, I pretty much am sure that you cannot do it any easier to cheaper with copy-on-write. The MODIFY bit, though, is something most MMUs have in hardware - not so for the VAX. :-(
That becomes important when you want to know if a page is dirty or not...
Johnny
On Dec 19, 2012, at 7:08 AM, Johnny Billquist wrote:
On 2012-12-19 03:27, Clem Cole wrote:
The page size on the VAX is 512 bytes and it lacked COW (copy-on-write)
HW (long, long story as to why, which I will not try to repeat). In
the end, this would be a huge problem with all VAX OSses and HW - take
look any of the sources.
[...]
Well, what it lacks (and I'm sure you know this) is really a modified bit in the page table.
However, it's extremely easy to implement it, and the cost is acceptable, I guess. You just keep the page read-only, and get a trap when someone wants to write. At that time you change the protection, and mark it as modified. There are even a couple of bits in the page entry that are reserved for software use, and you can just decide that one of them is your modified bit.
This is what we do in NetBSD/vax.
I can't imagine any other way of doing it. A copy on write page has to start out read-only, then when the write occurs the write has to be rejected so the copy can be done first. The "trap, copy, and write-enable" approach is the common one; for example, MIPS works exactly this way.
paul
