HECnet

hecnet@lists.dfupdate.se

2 participants
15583 discussions

by sampsa＠mac.com

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

12 years, 10 months

Who is Area 12?

by tim＠sneddon.id.au

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

12 years, 10 months

Who is Area 12?

by bqt＠softjar.se

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

12 years, 10 months

Who is Area 12?

by sampsa＠mac.com

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

12 years, 10 months

2.11BSD

by Paul_Koning＠Dell.com

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

12 years, 10 months

2.11BSD

by bqt＠softjar.se

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

12 years, 10 months

2.11BSD

by Paul_Koning＠Dell.com

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

12 years, 10 months

Expanding MONITOR CLUSTER to use full terminal screen?

by system＠TMESIS.COM

"Brian Schenkenberger, VAXman-" <system at TMESIS.COM> writes: "Brian Schenkenberger, VAXman-" <system at TMESIS.COM> writes: sampsa at mac.com writes: > >>Is there some switch I can use to make MONITOR CLUSTER use a larger >>screen than 80x24? > >I looked in the HELP commands but found nothing >related. > >??? > >I routinely have 132 column SHOW CLUSTER display. I have a number of >ADD commands in my SHOW_CLUSTER$INIT.INI file which cause SHOW CLUSTER >to use the full 132 columns of my display. What is the width of your >terminal? (ie. $ WRITE SYS$OUTPUT F$getdvi("TT","DEVBUFSIZ") returns >what?) Sorry, too early in the morn... MONITOR, not SHOW, CLUSTER. OK. I just checked the sources for MONITOR and this is fixed. Here's a comment from CLUFAO: ; The cluster screen in divided up into quadrants by a horizontal and verticle ; line. The quadrants are all equal in size (10 rows x 39 columns). The upper ; left quadrant displays the top 6 nodes CPU_BUSY statistic. The Upper right ; quadrant displays the top 6 MEMORY_UTILIZATION statistic. The lower left ; quadrant displays the top 6 disks total I/O rate statistic. And the lower ; left quadrant is up for grabs at this point. Following this comment, there's a table which contains cursor positioning values. All would maintain output that is strictly 80 column. If you're looking for a 132 column variant, it looks like you'll have to write this yourself. It should be pretty simple to do. -- 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, 10 months

Expanding MONITOR CLUSTER to use full terminal screen?

by system＠TMESIS.COM

"Brian Schenkenberger, VAXman-" <system at TMESIS.COM> writes: sampsa at mac.com writes: Is there some switch I can use to make MONITOR CLUSTER use a larger screen than 80x24? > >I looked in the HELP commands but found nothing related. ??? I routinely have 132 column SHOW CLUSTER display. I have a number of ADD commands in my SHOW_CLUSTER$INIT.INI file which cause SHOW CLUSTER to use the full 132 columns of my display. What is the width of your terminal? (ie. $ WRITE SYS$OUTPUT F$getdvi("TT","DEVBUFSIZ") returns what?) Sorry, too early in the morn... MONITOR, not SHOW, CLUSTER. -- 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, 10 months

Expanding MONITOR CLUSTER to use full terminal screen?

by system＠TMESIS.COM

sampsa at mac.com writes: Is there some switch I can use to make MONITOR CLUSTER use a larger screen than 80x24? I looked in the HELP commands but found nothing related. ??? I routinely have 132 column SHOW CLUSTER display. I have a number of ADD commands in my SHOW_CLUSTER$INIT.INI file which cause SHOW CLUSTER to use the full 132 columns of my display. What is the width of your terminal? (ie. $ WRITE SYS$OUTPUT F$getdvi("TT","DEVBUFSIZ") returns what?) -- 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, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet