TUHS

tuhs@tuhs.org

19 participants
6516 discussions

by Erik E. Fair

Which version of Unix first ran on a computer with virtual addressing (address translation) so that a process with non-position independent code (PIC) can be loaded anywhere in RAM that the kernel decided to put it, and memory protection such that no process could accidentally or deliberately access RAM not allocated to it by the kernel (or a SIGSEGV would be delivered to it)? Put another way, when did Unix processes stop playing Core War with each other? (OK, so long as no more than one is resident at a time, they can't play Core War with each other, but there still needs to be a mechanism to protect the kernel from inadvertent (or advertent) pointer use). Which is to say, when did Unix run on (and properly use) computers with memory management units (MMU)? My guess from a quick look at the history of the DEC PDP-11 is that the target computer was likely a PDP-11/35 or PDP-11/40 with a KT11-D "memory management" module. One imagines that many pointer mistakes (bugs) in assembly or C were discovered and squashed in that version, modulo the historical unhappiness resulting from address zero containing a zero if dereferenced ("NULL pointers") in process address space. What year did that come about? By the time I got to Unix (2.8BSD on the Cory Hall DEC PDP-11/70), those features (virtual addresses, memory protection from the kernel) had apparently been part of Unix for a long time - certainly earlier than Version 6. This is distinct from demand-paged virtual memory which so far as I know was developed on the DEC VAX-11. curious, Erik <fair(a)netbsd.org>

8 years, 6 months

Re: [TUHS] Unix & Memory Management Units (MMU)

by jnc＠mercury.lcs.mit.edu

> From: "Erik E. Fair" <f > One imagines that many pointer mistakes (bugs) in assembly or C were > discovered and squashed in that version, modulo the historical > unhappiness resulting from address zero containing a zero if > dereferenced ("NULL pointers") in process address space. PS: PDP-11 Unix didn't, I think, do much (anything?) to solve the null pointer problem. (This is for early C versions; I don't know about the later BSD ones.) Location 0 was a usable address for both read and write for everything except 'pure-text' (0410 magic word) processes; in those it was only legal for read. Address 0 mostly did not contain a 0, either; for C programs using the stock run-time, it contained a 'setd' instruction, except in split I+D processes, in which case data space location 0 probably (I'm too busy to spin up my V6 emulator to check) contained some of the program's initialized data (unless special arrangements had been made). Noel

8 years, 6 months

Re: [TUHS] Unix & Memory Management Units (MMU)

by jnc＠mercury.lcs.mit.edu

> From: "Erik E. Fair" > Which version of Unix first ran on a computer with virtual addressing That would be the first version to run on the PDP-11/45; I'm not sure which one that was, there's not enough left of Version 2 or Version 3 to see; Version 4 definitely ran on the 11/45: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/45.s > My guess from a quick look at the history of the DEC PDP-11 is that the > target computer was likely a PDP-11/35 or PDP-11/40 with a KT11-D > "memory management" module. No, they came after the -11/45 (with the KT11-C MMU). > What year did that come about? They got one of the first -11/45's, per a Unix history document I'm too busy to dig up, so 1972. Noel

8 years, 6 months

Re: [TUHS] looking for 4.1a BSD full kernel source

by Jason Stevens

I'm not sure if my other reply got though, so I'll try again... I found the source to the BBN stack in the CSRG CD's it's on CD 4 /sys/deprecated/bbnnet LINT.bbn 08-Aug-2016 06:37 3.5K NOTES 08-Aug-2016 06:37 4.6K RELAY.bbn 08-Aug-2016 06:37 1.2K SCCS/ 08-Aug-2016 06:37 - fsm.h 08-Aug-2016 06:37 1.2K fsmdef.h 08-Aug-2016 06:37 9.6K hmp.c 08-Aug-2016 06:37 12K hmp.h 08-Aug-2016 06:37 3.2K hmp_subr.c 08-Aug-2016 06:37 6.5K hmp_traps.c 08-Aug-2016 06:37 3.5K hmp_traps.h 08-Aug-2016 06:37 2.7K hmp_var.h 08-Aug-2016 06:37 1.4K ic_output.c 08-Aug-2016 06:37 5.7K icmp.c 08-Aug-2016 06:37 17K icmp.h 08-Aug-2016 06:37 3.3K in.c 08-Aug-2016 06:37 12K in.h 08-Aug-2016 06:37 2.0K in_pcb.c 08-Aug-2016 06:37 11K in_pcb.h 08-Aug-2016 06:37 1.9K in_proto.c 08-Aug-2016 06:37 4.9K in_var.h 08-Aug-2016 06:37 2.2K ip.h 08-Aug-2016 06:37 3.3K ip_input.c 08-Aug-2016 06:37 29K ip_output.c 08-Aug-2016 06:37 14K ip_usrreq.c 08-Aug-2016 06:37 3.8K macros.h 08-Aug-2016 06:37 4.4K net.h 08-Aug-2016 06:37 2.4K nopcb.h 08-Aug-2016 06:37 318 raw_input.c 08-Aug-2016 06:37 9.4K rdp.h 08-Aug-2016 06:37 15K rdp_cksum.s 08-Aug-2016 06:3 7 4.4K rdp_fsm.c 08-Aug-2016 06:37 4.5K rdp_input.c 08-Aug-2016 06:37 9.6K rdp_macros.h 08-Aug-2016 06:37 7.9K rdp_prim.c 08-Aug-2016 06:37 13K rdp_states.c 08-Aug-2016 06:37 34K rdp_subr.c 08-Aug-2016 06:37 8.4K rdp_usrreq.c 08-Aug-2016 06:37 21K seq.h 08-Aug-2016 06:37 415 sws.h 08-Aug-2016 06:37 326 tcp.h 08-Aug-2016 06:37 8.6K tcp_input.c 08-Aug-2016 06:37 12K tcp_prim.c 08-Aug-2016 06:37 9.8K tcp_procs.c 08-Aug-2016 06:37 28K tcp_states.c 08-Aug-2016 06:37 20K tcp_usrreq.c 08-Aug-2016 06:37 22K udp.c 08-Aug-2016 06:37 5.2K udp.h 08-Aug-2016 06:37 1.1K udp_usrreq.c 08-Aug-2016 06:37 7.0K I've been meaning to try to try to manually mash stuff together but just haven't gotten around to it. > ---------- > From: Paul Ruizendaal > Sent: Thursday, December 1, 2016 4:30 PM > To: tuhs(a)minnie.tuhs.org > Subject: [TUHS] looking for 4.1a BSD full kernel source > > > Hi, > > I'm trying to find out exactly what was in the 4.1a BSD distribution, as > far as the kernel is concerned. The image in the CSRG archive comes from a > tape that had a hard read error and does not include any kernel sources. > Some of the kernel files were already covered by SCCS around that time, > but not everything. My main focus is to understand tcp/ip networking in > 4.1a and whether the kernel could be built with either the Berkeley or the > BBN network stack. > > Does anybody know where I could find a full set of kernel sources for the > 4.1a BSD kernel? > > Many thanks in advance! > > Paul >

8 years, 6 months

The History of Unix

by Angus Robinson

Hi I am sure there must have been an email about this if so, I do apologies. The below link is from Diomidis Spinellis work, I remember seeinng an email from him a few months ago requesting some information about the history of BSD. Looking at it, he has done some amazing work. I look forward to playing with 386BSD! https://github.com/dspinellis/unix-history-repo

8 years, 6 months

looking for source code to University of Illinois "Network Unix"

by Paul Ruizendaal

Hi, I'm looking for the source code to "Network Unix" as described here: https://tools.ietf.org/html/rfc681 and/or its later development described here: https://archive.org/details/networkunixsyste243kell Actually, I'd be happy with finding the source code to any version of this Network Unix. This version of Unix had fairly wide use in the Arpanet community and was in use at several universities and organizations (e.g.: Rand, BBN, etc.) Would anybody here know of a surviving copy? Many thanks in advance, Paul

8 years, 6 months

Re: [TUHS] looking for 4.1a BSD full kernel source

by Paul Ruizendaal

Hi Diomidis, Thanks for that link. This is exactly what I'm trying to ascertain, and I'm finding conflicting evidence. - The socket API was in a state of flux between October '81 and March '82 (when 4.1a was supposedly cut). By March '82 it was mostly there, but not until later in the year did it fully stabilize. - The BBN stack did not use the sockets API as late as January '82 - What I currently fathom from the SCCS files is that the socket API implementation was hard coded to use the nascent Berkeley stack. - But the BBN code was likely in the 4.x BSD source tree, outside of SCCS (Berkeley started out with the BBN code, but it morphed quite quickly and drastically) - In 1985 the BBN code finally enters SCCS (marked 'deprecated'); this code was integrated with the sockets API, and much developed from its 1982 form Either the below link is correct (and I think I may have contributed to its view in a private mail to Kirk), or there were two different distributions (4.1a BSD with Berkeley network code and 4BSD with BBN network code). The two may have merged into one in peoples' memories: 35 years is a long time. Finding the actual kernel source for the 4.1a distribution could provide clarity on this point. Perhaps Bill Joy could shed some light on the issue, but I don't have contact details. Having actual source removes all doubt. Paul On 1 Dec 2016, at 10:51 , Diomidis Spinellis wrote: > The best description I could find is the following: > > http://minnie.tuhs.org/pipermail/tuhs/2016-September/007417.html > > > The 4.1a distribution had the initial socket interface with a > > prerelease of the BBN TCP/IP under it. There was wide distribution > > of 4.1a. The 4.1b distribution had the fast filesystem added and > > a more mature socket interface (notably the listen/accept model > > added by Sam Leffler). > > Diomidis > > On 01/12/2016 10:30, Paul Ruizendaal wrote: >> >> Hi, >> >> I'm trying to find out exactly what was in the 4.1a BSD distribution, as far as the kernel is concerned. The image in the CSRG archive comes from a tape that had a hard read error and does not include any kernel sources. Some of the kernel files were already covered by SCCS around that time, but not everything. My main focus is to understand tcp/ip networking in 4.1a and whether the kernel could be built with either the Berkeley or the BBN network stack. >> >> Does anybody know where I could find a full set of kernel sources for the 4.1a BSD kernel? >> >> Many thanks in advance! >> >> Paul >> >

8 years, 6 months

looking for 4.1a BSD full kernel source

by Paul Ruizendaal

Hi, I'm trying to find out exactly what was in the 4.1a BSD distribution, as far as the kernel is concerned. The image in the CSRG archive comes from a tape that had a hard read error and does not include any kernel sources. Some of the kernel files were already covered by SCCS around that time, but not everything. My main focus is to understand tcp/ip networking in 4.1a and whether the kernel could be built with either the Berkeley or the BBN network stack. Does anybody know where I could find a full set of kernel sources for the 4.1a BSD kernel? Many thanks in advance! Paul

8 years, 6 months

Re: [TUHS] RIP J.F.Ossanna

by Norman Wilson

Larry McVoy: I've always morned that he died so early. I would have liked to talk to him, I love troff to this day. ==== Me too (s/morn/mourn/, of course). I might even have had the chance to work with him. The original UNIX crowd were all really neat characters, albeit sometimes a trifle overly characterful. All nice guys to work with, too, at least those who were still around when I was at 1127. Norman Wilson Toronto ON

8 years, 6 months

RIP J.F.Ossanna

by Dave Horsfall

We lost J.F.Ossanna in 1977; he had a hand in developing Unix, and was responsible for "roff" and its descendants. Remember him, the next time you see "jfo" in documentation. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

8 years, 6 months

Grace Hopper

by Rudi Blom

Probably most read about it, but just FYI "Grace Hopper and Margaret Hamilton awarded Presidential Medal of Freedom for computing advances" https://techcrunch.com/2016/11/17/grace-hopper-and-margaret-hamilton-awarde… Grace's wiki page shows a 'real' computer bug :-)

8 years, 6 months

Retro UNIX 8086 / 80386

by Jason Stevens

I stumbled onto this by accident, and yes it really is a port of UNIX v1 from PDP-11 assembly into 8086/80386 assembly. I fired up Qemu and some of the disk images and it booted up! the directories contain assembly, text files, pdf's, images, and pictures... I have no idea how to build it I didn't see any make file, but it looks very interesting! http://www.singlix.com/runix/index.html Also you may want to mute the tab, or turn your speakers down, it has an embedded music player.

8 years, 6 months

another Unix V7 port

by Nelson H. F. Beebe

I just found a project that has ported Unix V7 to a modern system, and a search of my TUHS archives finds no previous mention of it: V7/x86 - x86 port of UNIX V7 http://www.nordier.com/v7x86/index.html V7/x86 on VirtualBox http://www.nordier.com/articles/v7x86_vbox.html The jwhois command identifies the host site as (possibly) located in Durban, South Africa. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

8 years, 6 months

Re: [TUHS] TUHS Digest, Vol 12, Issue 5

by David

Can’t help about that DEC-ism. Do have these 2. News from Xerox Corporation: FOR IMMEDIATE RELEASE XEROX ANNOUNCES HYPER-ETHERNET SAN FRANCISCO, CA. Jan 7. 2010 - Xerox today announced Hyper-Ethernet their fourth generation local area network. In addition to its ability to transmit text data and images, Hyper- Ethernet enables the transmission of people. ”People transmission over Hyper-Ethernet" according to Michael Liddle, V.P. of Office Systems. "will greatly reduce elevator congestion and eliminate the need for video conferencing.“ Order taking for Hyper-Ethemet will begin next month. Installation will start in Los Angeles in the Third Quarter. In a related announcement. Wang Labs. headquartered in Hoboken. New Jersey, announced Super- Hyper Wangnet their twelfth generation local area network. According to Freddie Wang, President of Wang Labs. "Super-Hyper-Wangnet will not only transmit people over the Wangband, but will also transmit furniture and buildings over the interconnect and utility bands. These additional capabilities of Super-Hyper Wangnet are vital to the emerging office of the future." Order taking for Super-Hyper-Wangnet will begin next month. Installation has already occurred worldwide. IBM Corporation. who has been rumored to be about to announce a local area network since 1980, was not available for comment. xxx Followed by Digital Responds to Hyper-Ethernet TEWKSBURY. MA. April 1. 2010 -- Digital Equipment announced today it's new DECnet Phase XVIII Architecture. In response to recent Xerox and Wang improvements to Ethernet that provide people and facility transportation across inter-node links DEC‘s latest DECnet provides these capabilities as well as providing for the creation of virtual facilities and even countries. These capabilities are provided by breakthroughs in communications technology that actually uses the Ether as a communications media. Through the use of a new dedicated NANO-PDP-11/E99 gateway processor system, ETHERGATE, DECnet users can access anywhere in the Ethereal Plane. This development obsoletes teleconferencing, since meeting groups can create their own common conference rooms and cafeterias, thus resolving space, travel and dining problems. There may be a few bugs left, as some of the dissenting DECnet Review Group members have not been seen since the last meeting held in such a virtual conference facility. This breakthrough was brought about by a team effort of the Distributed Systems‘ Software and Hardware engineering teams in a effort to improve on their Tewksbury, Massachusetts facility. In a compromise decision, Distributed Systems will maintain an ETHERGATE in TWOOO, but it will connect directly to their new home somewhere in the Shire of their newly deﬁned Middle Earth reality. Despite some difﬁculties, the scenery, windows tax breaks, pool and racquetball courts made the relocation go quite smoothly. Engineering Network topology will not change, as all forwarding will be done by the TWOOO Ethereal Plane Router residing in the crater at the former building site. Utility packages such as Ethereal Person Transfer (EPT) and Ethereal Facility Transfer (EFT) provide appropriate capabilities for casual users. Sophiscated users can create (SCREATE), access (SOPEN), and delete (SNUKE) ethereal entities transparently from high level languages using the Ethereal Management System (EMS) package and the Ethereal Access Protocol (EAP). An ETHERTRIEVE utility for easy interactive use will be available shortly. DECnet Phase XVIII follows on the success of the Phase XVI ability to access everyone‘s Digital Professional wrist watch computer system. This lead to the current Phase XVII architecture, which has routing capabilities that allow direct communications with the entire Earth population's Atari home video games. Distributed Systems architects are hard at work on the next phase of DECnet that will include multi-plane existence network management (using the NIECE protocol) and galaxy level routing using 64K bit addresses. Digital will continue to support it's Gateway products into the Prime Material Plane. These products include an IBM ANA (Acronym-based Network Architecture) Gateway, the TOLKIEN product that allows control of all ring based networks, and our Mega-broad-jump-band hardware which leaps past Wang's products in the hype weary business marketplace. From our Engineering Net. (You can tell that they're really working on on it. Racquetball courts indeed!) David > On Nov 17, 2016, at 6:00 PM, tuhs-request(a)minnie.tuhs.org wrote: > > Send TUHS mailing list submissions to > tuhs(a)minnie.tuhs.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs > or, via email, send a message with subject or body 'help' to > tuhs-request(a)minnie.tuhs.org > > You can reach the person managing the list at > tuhs-owner(a)minnie.tuhs.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TUHS digest..." > > > Today's Topics: > > 1. OT: USENET article involving DEC machines and atomic tests > (Dave Horsfall) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 18 Nov 2016 11:54:40 +1100 (EST) > From: Dave Horsfall <dave(a)horsfall.org> > To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> > Subject: [TUHS] OT: USENET article involving DEC machines and atomic > tests > Message-ID: <alpine.BSF.2.11.1611181148020.19595(a)aneurin.horsfall.org> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Hoping someone can help me here, as I've grepped the 'net to no avail. > > Back when USENET was supreme and dinosaurs strode the earth, there was a > hilarious article involving a DEC box (long forgotten it) that was used to > instrument underground atomic tests. In one scene, the box was atop a > truck which was right over the hole; they both went skywards, but the data > was recovered by taking out the core memory boards and plugging them into > another box. > > Does anyone remember it? It does sound rather suss... > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > TUHS mailing list > TUHS(a)minnie.tuhs.org > http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs > > ------------------------------ > > End of TUHS Digest, Vol 12, Issue 5 > ***********************************

8 years, 6 months

OT: USENET article involving DEC machines and atomic tests

by Dave Horsfall

Hoping someone can help me here, as I've grepped the 'net to no avail. Back when USENET was supreme and dinosaurs strode the earth, there was a hilarious article involving a DEC box (long forgotten it) that was used to instrument underground atomic tests. In one scene, the box was atop a truck which was right over the hole; they both went skywards, but the data was recovered by taking out the core memory boards and plugging them into another box. Does anyone remember it? It does sound rather suss... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

8 years, 6 months

Re: [TUHS] Booting PDP-11's from RX02's

by jnc＠mercury.lcs.mit.edu

> From: Don North > Track 0 is not used by standard DEC software I wonder why DEC did't use track 0. The thing is small enough (256KB in the original single-density) that even 1% is a good chunk to throw away. Does anyone know? (I had a look online, but couldn't turn anything up.) If I had to _guess_, one possibility would be that track 0 is the innermost track, where the media is moving the slowest, and as a result it's more error-prone. Another is that IBM used track 0 for something special, and DEC tried to conform with that. But those are pure guesses, I would love to know for sure. Noel

8 years, 7 months

Re: [TUHS] Booting PDP-11's from RX02's

by jnc＠mercury.lcs.mit.edu

> From: Don North <north(a)alum.mit.edu> > .. the hardware bootstrap reads track 1 sectors 1, 3, 5, 7 Ah, thanks for that. Starting to look at the code, I had missed the interleave. So does DEC do anything with track 0, or is it always just empty? Noel

8 years, 7 months

Booting PDP-11's from RX02's

by jnc＠mercury.lcs.mit.edu

So, I'm winding up to boot Unix V6 from an RX02 floppy. So I need two things: - Details of how DEC ROM bootstraps boot from RX02's. I vaguely recall seeing documentation of this somewhere (e.g. which sectors it loads, etc), but now I can't find it. Don North has dumps of the RX02 ROM's, but I'm too lazy to read through the code and figure out how they work. Is there some documentation which covers it? I did a quick Google search, but if there is anything out there, my Google-fu was inadequate. - Did anyone ever do an RX02 driver for the V6 disk bootstrap? (Well, I guess a V7 driver would work, too.) Note: what I need is _not_ either i) the Unix OS driver for the RX02 (I found one of those already), or ii) a driver for the v7 standalone second-stage bootstrap (which would probably be in C). The thing I'm looking for would be called rx.s, or something like that. Yes, I could write it, but again, I'm lazy! :-) Noel

8 years, 7 months

Re: [TUHS] VTServer/etc for V6 Unix

by jnc＠mercury.lcs.mit.edu

> From: Jacob Goense <dugo(a)xs4all.nl> > There is the issue with the non-existing man command. My page on "Bringing up V6 Unix on the Ersatz-11 PDP-11 Emulator" has a section on man: http://mercury.lcs.mit.edu/~jnc/tech/V6Unix.html#man It's pretty straight-forward. Noel

8 years, 7 months

Re: [TUHS] VTServer/etc for V6 Unix

by jnc＠mercury.lcs.mit.edu

So, in a fit of brain-fade, I originally sent this to the Classic Computers list, when it was probably really more appropriate for this one. (Apologies to those who are subscribed to both, and are thus seeing this again.) So, I'm trying to do what VTServer was invented for - load Unix into an actual PDP-11, over its serial line, when one doesn't have machine-readable Unix on any mass storage for the machine. However, all the initial code that VTServer loads ('mkfs', etc) is V7-specific (V6 has a slightly different file system format) - and I want to install V6. Has anyone ever tweaked the programs which VTServer loads to do V6-format filesystems? I did a quick Google, but didn't see anything. Another option is to do something more V6-like, and copy a small bootable V6 file-system image over the serial line; that may be an easier way to go. No biggie if not, it won't be much work to adapt things, but I figured I'd try to avoid re-inventing the wheel... Note that the installation procedures for V6 and V7 are wholly different, something which confused a number of people on CCTalk. The 'Setting up Unix' documents are more checklists, they don't go into a lot of detail as to what is actually happening, so I have prepared two pages on the Computer History wiki: http://gunkies.org/wiki/Installing_UNIX_Sixth_Edition http://gunkies.org/wiki/Installing_UNIX_Seventh_Edition which go into more detail on what is actually happening. Noel

8 years, 7 months

Re: [TUHS] VTServer/etc for V6 Unix

by jnc＠mercury.lcs.mit.edu

> I'll start with getting VTServer to run under V6 (my only Unix, don't > have anything later :-) So, I just got VTServer runnin under V6: it successfully loaded a memory diagnostic from the 'server', into the 'client', using 'vtboot' on the latter. (Both running on emulated machines, for the moment - I thought I'd take all the hardware-related variables out of the equation, until I have the software all running OK.) It didn't require as much work on VTServer as I thought it might: I had to convert the C to the V6 dialect (no '+=', etc), and some other small things (e.g. convert the TTY setup code), but in general, it was pretty smooth and painless. Note that it won't run under vanilla V6, which does not provide 8-bit input and output on serial lines. I had previously added 'LITIN' and 'LITOUT' modes (8-bit input and output) to my V6; since the mode word in stty/gtty was already full, I had to extend the device interface to support them. I didn't add ioctl() or anything later, I did an upward-compatible extension to stty/gtty. (I'm a real NIH guy. :-) My only real problem in getting VTServer running was with LITIN; I did it some while back, but had never actually tested it (I was only using LITOUT, for my custom program to talk to PDP-11 consoles, which also did downloads, so needed 8-bit output). So when I went to use it, it didn't work, and it was a real stumper! But I did eventually figure out what the problem was (after writing a custom program to reach into the kernel and dump the entire state of a serial line), and get it working. (I had taken the shortcut of not fully understanding how the kernel serial line code worked, just tried to install point fixes. This turned out not to work, because of a side-effect elsewhere in the code. Moral of the story: you can't change the operation of a piece of software without complete understanding of how it works...) Is there any interest in all this? If so, I can put together a web page with the V6-verion VTServer source, along with the modified V6 serial line stuff (including a short description of the extended stty/gtty interface), etc. > so if you turn up whatever you used to boot V6, it would probably still > be useful. So I guess my next step, if I don't hear shortly from someone who has previously used VTServer to install V6, is to start on actually getting a V6 file system created. I'm still vacillating over whether it would be better to go V6-style (and just transfer a complete, small existing V6 filesystem), or V7-style (and get stand-alone 'mkfs', etc running with V6-format file systems). Anyone have an opinion? Noel

8 years, 7 months

Re: [TUHS] export TERM=aaa-60

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > I miss my AAA Well, I'm not sure I actually _miss_ mine (my old eyes prefer black on white), but I definitely have fond memories of it. It was such a huge thing when I finally managed to snag one to replace my (IIRC) VT52. You could actually have three useful windows in Emacs!! And the detached keyboard was definitely more ergonomic. Noel

8 years, 7 months

export TERM=aaa-60

by Ramakrishnan Muthukrishnan

Found this nice blog post today on the interweb that this group may find very interesting.... <https://www.jwz.org/blog/2016/10/export-termaaa-60/> -- Ramakrishnan

8 years, 7 months

[OT] VAXen, my children, just don't belong some places

by Dave Horsfall

Time to post this again; warning: you need to uderstand the obscure references... I've actually worked in places like this. ----- VAXen, my children, just don't belong some places. In my business, I am frequently called by small sites and startups having VAX problems. So when a friend of mine in an Extremely Large Financial Institution (ELFI) called me one day to ask for help, I was intrigued because this outfit is a really major VAX user - they have several large herds of VAXen - and plenty of sharp VAXherds to take care of them. So I went to see what sort of an ELFI mess they had gotten into. It seems they had shoved a small 750 with two RA60's running a single application, PC style, into a data center with two IBM 3090's and just about all the rest of the disk drives in the world. The computer room was so big it had three street addresses. The operators had only IBM experience and, to quote my friend, they were having "a little trouble adjusting to the VAX", were a bit hostile towards it and probably needed some help with system management. Hmmm, Hostility... Sigh. Well, I thought it was pretty ridiculous for an outfit with all that VAX muscle elsewhere to isolate a dinky old 750 in their Big Blue Country, and said so bluntly. But my friend patiently explained that although small, it was an "extremely sensitive and confidential application." It seems that the 750 had originally been properly clustered with the rest of a herd and in the care of one of their best VAXherds. But the trouble started when the Chief User went to visit his computer and its VAXherd. He came away visibly disturbed and immediately complained to the ELFI's Director of Data Processing that, "There are some very strange people in there with the computers." Now since this user person was the Comptroller of this Extremely Large Financial Institution, the 750 had been promptly hustled over to the IBM data center which the Comptroller said, "was a more suitable place." The people there wore shirts and ties and didn't wear head bands or cowboy hats. So my friend introduced me to the Comptroller, who turned out to be five feet tall, 85 and a former gnome of Zurich. He had a young apprentice gnome who was about 65. The two gnomes interviewed me in whispers for about an hour before they decided my modes of dress and speech were suitable for managing their system and I got the assignment. There was some confusion, understandably, when I explained that I would immediately establish a procedure for nightly backups. The senior gnome seemed to think I was going to put the computer in reverse, but the apprentice's son had an IBM PC and he quickly whispered that "backup" meant making a copy of a program borrowed from a friend and why was I doing that? Sigh. I was shortly introduced to the manager of the IBM data center, who greeted me with joy and anything but hostility. And the operators really weren't hostile - it just seemed that way. It's like the driver of a Mack 18 wheeler, with a condo behind the cab, who was doing 75 when he ran over a moped doing its best to get away at 45. He explained sadly, "I really warn't mad at mopeds but to keep from runnin' over that'n, I'da had to slow down or change lanes!" Now the only operation they had figured out how to do on the 750 was reboot it. This was their universal cure for any and all problems. After all it works on a PC, why not a VAX? Was there a difference? Sigh. But I smiled and said, "No sweat, I'll train you. The first command you learn is HELP" and proceeded to type it in on the console terminal. So the data center manager, the shift supervisor and the eight day operators watched the LA100 buzz out the usual introductory text. When it finished they turned to me with expectant faces and I said in an avuncular manner, "This is your most important command!" The shift supervisor stepped forward and studied the text for about a minute. He then turned with a very puzzled expression on his face and asked, "What do you use it for?" Sigh. Well, I tried everything. I trained and I put the doc set on shelves by the 750 and I wrote a special 40 page doc set and then a four page doc set. I designed all kinds of command files to make complex operations into simple foreign commands and I taped a list of these simplified commands to the top of the VAX. The most successful move was adding my home phone number. The cheat sheets taped on the top of the CPU cabinet needed continual maintenance, however. It seems the VAX was in the quietest part of the data center, over behind the scratch tape racks. The operators ate lunch on the CPU cabinet and the sheets quickly became coated with pizza drippings, etc. But still the most used solution to hangups was a reboot and I gradually got things organized so that during the day when the gnomes were using the system, the operators didn't have to touch it. This smoothed things out a lot. Meanwhile, the data center was getting new TV security cameras, a halon gas fire extinguisher system and an immortal power source. The data center manager apologized because the VAX had not been foreseen in the plan and so could not be connected to immortal power. The VAX and I felt a little rejected but I made sure that booting on power recovery was working right. At least it would get going again quickly when power came back. Anyway, as a consolation prize, the data center manager said he would have one of the security cameras adjusted to cover the VAX. I thought to myself, "Great, now we can have 24 hour video tapes of the operators eating Chinese takeout on the CPU." I resolved to get a piece of plastic to cover the cheat sheets. One day, the apprentice gnome called to whisper that the senior was going to give an extremely important demonstration. Now I must explain that what the 750 was really doing was holding our National Debt. The Reagan administration had decided to privatize it and had quietly put it out for bid. My Extreme Large Financial Institution had won the bid for it and was, as ELFIs are wont to do, making an absolute bundle on the float. On Monday the Comptroller was going to demonstrate to the board of directors how he could move a trillion dollars from Switzerland to the Bahamas. The apprentice whispered, "Would you please look in on our computer? I'm sure everything will be fine, sir, but we will feel better if you are present. I'm sure you understand?" I did. Monday morning, I got there about five hours before the scheduled demo to check things over. Everything was cool. I was chatting with the shift supervisor and about to go upstairs to the Comptroller's office. Suddenly there was a power failure. The emergency lighting came on and the immortal power system took over the load of the IBM 3090s. They continued smoothly, but of course the VAX, still on city power, died. Everyone smiled and the dead 750 was no big deal because it was 7 AM and gnomes don't work before 10 AM. I began worrying about whether I could beg some immortal power from the data center manager in case this was a long outage. Immortal power in this system comes from storage batteries for the first five minutes of an outage. Promptly at one minute into the outage we hear the gas turbine powered generator in the sub-basement under us automatically start up getting ready to take the load on the fifth minute. We all beam at each other. At two minutes into the outage we hear the whine of the backup gas turbine generator starting. The 3090s and all those disk drives are doing just fine. Business as usual. The VAX is dead as a door nail but what the hell. At precisely five minutes into the outage, just as the gas turbine is taking the load, city power comes back on and the immortal power source commits suicide. Actually it was a double murder and suicide because it took both 3090s with it. So now the whole data center was dead, sort of. The fire alarm system had its own battery backup and was still alive. The lead acid storage batteries of the immortal power system had been discharging at a furious rate keeping all those big blue boxes running and there was a significant amount of sulfuric acid vapor. Nothing actually caught fire but the smoke detectors were convinced it had. The fire alarm klaxon went off and the siren warning of imminent halon gas release was screaming. We started to panic but the data center manager shouted over the din, "Don't worry, the halon system failed its acceptance test last week. It's disabled and nothing will happen." He was half right, the primary halon system indeed failed to discharge. But the secondary halon system observed that the primary had conked and instantly did its duty, which was to deal with Dire Disasters. It had twice the capacity and six times the discharge rate. Now the ear splitting gas discharge under the raised floor was so massive and fast, it blew about half of the floor tiles up out of their framework. It came up through the floor into a communications rack and blew the cover panels off, decking an operator. Looking out across that vast computer room, we could see the air shimmering as the halon mixed with it. We stampeded for exits to the dying whine of 175 IBM disks. As I was escaping I glanced back at the VAX, on city power, and noticed the usual flickering of the unit select light on its system disk indicating it was happily rebooting. Twelve firemen with air tanks and axes invaded. There were frantic phone calls to the local IBM Field Service office because both the live and backup 3090s were down. About twenty minutes later, seventeen IBM CEs arrived with dozens of boxes and, so help me, a barrel. It seems they knew what to expect when an immortal power source commits murder. In the midst of absolute pandemonium, I crept off to the gnome office and logged on. After extensive checking it was clear that everything was just fine with the VAX and I began to calm down. I called the data center manager's office to tell him the good news. His secretary answered with, "He isn't expected to be available for some time. May I take a message?" I left a slightly smug note to the effect that, unlike some other computers, the VAX was intact and functioning normally. Several hours later, the gnome was whispering his way into a demonstration of how to flick a trillion dollars from country 2 to country 5. He was just coming to the tricky part, where the money had been withdrawn from Switzerland but not yet deposited in the Bahamas. He was proceeding very slowly and the directors were spellbound. I decided I had better check up on the data center. Most of the floor tiles were back in place. IBM had resurrected one of the 3090s and was running tests. What looked like a bucket brigade was working on the other one. The communication rack was still naked and a fireman was standing guard over the immortal power corpse. Life was returning to normal, but the Big Blue Country crew was still pretty shaky. Smiling proudly, I headed back toward the triumphant VAX behind the tape racks where one of the operators was eating a plump jelly bun on the 750 CPU. He saw me coming, turned pale and screamed to the shift supervisor, "Oh my God, we forgot about the VAX!" Then, before I could open my mouth, he rebooted it. It was Monday, 19-Oct-1987. VAXen, my children, just don't belong some places. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." _______________________________________________ Applix 1616 mailing list Applix-L(a)object-craft.com.au https://www.object-craft.com.au/cgi-bin/mailman/listinfo/applix-l

8 years, 7 months

Re: [TUHS] [OT] VAXen, my children, just don't belong some places

by jnc＠mercury.lcs.mit.edu

> From: Random832 > Tapes are still bigger than disks, to my understanding. Makes sense. There's a lot more surface area on a tape than on a disk. Yes, mechanical considerations mean you can pack the bits on a disk in more densely, but not enough to offset the much greater surface area. Noel

8 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS