HECnet

hecnet@lists.dfupdate.se

15586 discussions

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, 12 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, 12 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, 12 months

Expanding MONITOR CLUSTER to use full terminal screen?

by sampsa＠mac.com

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. sampsa

12 years, 12 months

2.11BSD

by clemc＠ccc.com

Correct. Not having it is expensive, and adds difficulties to the SW. This is why wnj created/implemented vfork(2) for 4.1. While most codes could just s/fork/vfork/ careful reading needed to occur and some rewriting needed to happen. The HW guys finally relented. On Wed, Dec 19, 2012 at 7:08 AM, Johnny Billquist <bqt at softjar.se> wrote: Well, what it lacks (and I'm sure you know this) is really a modified bit in the page table.

12 years, 12 months

2.11BSD

by bqt＠softjar.se

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 don't know of any architecture that has any kind of copy-on-write semantics in the MMU. I think that is way to complex to actually be possible in the MMU itself. OSes normally do copy-on-write by having the page read-only, and when a write happens, the page gets cloned, and then you have your own private copy, to which you can write. But that implies allocating a new page, copy the contents of the old page over, and change the current page table. If you know of an MMU that can do that, I'm interested in hearing about it. Johnny

12 years, 12 months

Post-mail server migration test post/area status

by gregg.drwho8＠gmail.com

On Wed, Dec 19, 2012 at 1:10 AM, Cory Smelosky <b4 at gewt.net> wrote: Feel free to disregard, I was just playing with SPF records and I migrated away from gmail and wanted to make sure emails still get places properly. Had to make sure, always a chance I broke something. ;) Also: I will very soon have time to get back to making area 9 work. Hello! Disregard what? It works. Good for you. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again."

12 years, 12 months

Post-mail server migration test post/area status

by b4＠gewt.net

Feel free to disregard, I was just playing with SPF records and I migrated away from gmail and wanted to make sure emails still get places properly. Had to make sure, always a chance I broke something. ;) Also: I will very soon have time to get back to making area 9 work.

12 years, 12 months

2.11BSD

by clemc＠ccc.com

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. Us OS guys were basically driven nuts at time about it and there were huge fights with the HW team. Only after all the trouble the VAX MMU caused the OS team, and many of the same folks were working on a different system did we get Dave Cane to relent and he gathered up Tom Teixiera, Terry Hayes, myself and we [the OS team] essentially designed a different MMU (IIRC correctly it was 4K page, but I've forgotten and I'm traveling so I can not look at doc in my basement). I should note that Dave is really is one best HW guys I ever worked with - he had previously led the VAX 750 development and was part of the 780. He is one of the people I most respect from those days. As a side note, about 2-3 years later with the 386/486 Intel put the MMU "on-die" and Moto would follow suite. Once that happened the MMU and the CPU pretty much were married and you see things become a lot more standardized. But to Intel and friends credit that got learn from all of the others and decide what worked and what did not. FYI: if you look at the MMU in the R2000-R4000 [which fairly soft] and then the Alpha, you'll see the logical progression of what HW was needed, how the TLB (or "TB" if you came from the other religion) was what really mattered. The reality is that SW (the OS) started to really influence the MMU design more than it had 10 years before - particularly as the different UNIX flavors became the world of the day. If you want to understand it and how it came about, there is a really great discussion of all of this is Curt Schimmell's "UNIX Systems for Modern Architectures: Symmetric Multiprocessing and Caching for Kernel Programmers" On Tue, Dec 18, 2012 at 7:39 PM, Johnny Billquist <bqt at softjar.se> wrote: On 2012-12-18 19:05, Clem Cole wrote: Paul. given the time (late 1960's/early 70's) the prevailing page sizes were 64 / 128 / 256 / 512 bytes which just happen to map to the sizes of blocks used in disk controllers. 1/4/8 k pages were a few years in the future. by the virtual address extension to the 11 ( aka 1975 's vax 11/780) DEC switched to 512 bytes. That said as wnj would point out in the "fast vax" paper by 1979 512 bytes was to small. Um... The page size of the PDP-11 is 8K. :-) Johnny Clem On Dec 18, 2012, at 9:45 AM, <Paul_Koning at Dell.com> wrote: On Dec 17, 2012, at 6:01 PM, Johnny Billquist wrote: On 2012-12-17 23:50, Boyanich, Alastair wrote: ... 2) Was 2.11BSD ever ported to other platforms? Given the age/era, I'm curious about 8088/8086/NECv20/80286 given the banked memory models used and looking at the 8088/8086 XENIX disassembly. Nope. That would not have been 2BSD then. And since the PDP-11 don't even have banked memory, it would probably cause some headaches to port 2BSD to something like 80286 or other similar machines. To make it clear - the PDP-11 have a very normal MMU with pages. Semi-normal. It's rather unusual in that it has a paged MMU with page address granularity different from the page size (64 bytes vs. 8k bytes). Most architectures have those two match, that avoids an adder -- consider VAX or MIPS or Alpha. paul -- 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, 12 months

Phase V Routing Specification

by Paul_Koning＠Dell.com

On Dec 18, 2012, at 6:58 PM, Rob Jarratt wrote: -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com Sent: 18 December 2012 22:30 To: hecnet at Update.UU.SE Subject: Re: [HECnet] Phase V Routing Specification On Dec 18, 2012, at 5:07 PM, Rob Jarratt wrote: http://bitsavers.trailing-edge.com/pdf/dec/decnet/EK-DNAPV- GD_DECnet_Phase_V_General_Description_Sep87.pdf Thanks for the link. I had a quick look. It does not go into the details of the message formats, but it does say it interoperates with Phase IV, so I just wonder if it was sufficient for me to accept Phase V messages as if they were Phase IV and just ignore the version bytes. I might just give that a quick go, which host is Phase V on HECnet now? The way to interoperate with a version newer than what you implement is to speak the protocol as you know it. That includes ignoring fields you're supposed to ignore, and messages for protocols (such as Ethertypes or 802.2 DSAPs) you don't implement. If you do that, the rest is up to the newer version. What I am doing is checking for routing specification 2.0.0 (in the hello messages), but not checking for later versions. I have disabled the check temporarily and it seems to work. But I seem to be getting EthernetRouterHello messages from node 12.2 with the R/S LIST always empty, so I never get an adjacency with the node. Not sure if this is because I am not sending myself to 12.2, but an empty list suggests it can't talk to any of the other routers in the network. I see... yes, the way to handle version numbers is in the spec. Basically, it follows the principle I described. Examine the received version number. If it's less than yours, speak that version (if you know how). If it's the same, or greater, speak your version. If the other end announces a greater version number, it will speak to you in what you announced, or give up if it doesn't know how to do that. This rule is used consistently in DECnet -- we defined this at some point as the general rule of version numbers, it's the easy and reliable way for cross-version compatibility to work. All it requires is that you can find the version number in the first message you see. (For example, in III-IV compatibility, if I remember right, the version number in the first message is checked first even though a bunch of fields precede it, because those fields depend on the version number. Or maybe I'm thinking of II-III compatibility. I can find the code if I search long enough... it was somewhere in DECnet/E.) paul

12 years, 12 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet