TUHS

tuhs@tuhs.org

19 participants
6516 discussions

Re: [TUHS] Names of famous, historical UNIX machines?

by Berny Goodheart

You might find this interesting reading: http://www.livinginternet.com/u/ui_netexplodes.htm <http://www.livinginternet.com/u/ui_netexplodes.htm> In particular inhp4. I used to have a UUCP map that linked me into this network back in the mid 80s. I was based in the UK doing some work for Henry Spencer at Microport Systems if any of you recall their iX286 System V port, which was pretty cool. Anyway, there are some interesting machine names mentioned. From: smb(a)ulysses.att.com Subject: Re: IHNP4 Date: Thu, 25 Oct 90 20:48:42 EDT > Thus, ihnp4 was Indian Hill Network Processor #4 > mh was Murray Hill. ak was the Atlanta Wire Works, sb was Southern > Bell, cb was Columbus (Mark Horton was mark@cbosgd for a long time) > plus others. Yup, Columbus Operating Systems Group D, as I recall. > Then there were the machines in the lab that had (and have) names like > bonnie, clyde, ulysses, research, allegra, lento, harpo, chico, etc.

8 years, 4 months

Re: [TUHS] Names of famous, historical UNIX machines?

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > my printers have often been named after chainsaws Yeah, MIT (or was it Proteon, I forget - a long time ago :-) had that theme going for a while for printers... > @ DEC we were pretty free to use what we wanted and some were themed, > most were boring. Hah! I do have a cosmically great computer naming story from DEC, though. So DECNet host names were limited to N characters (where N=8, or some such). So one day they get this complaint from some DEC user in the UK: "Grumble, grumble, grumble, N-character limit in DECNet host names, we want to name our host 'Slartibartfast'." So, this being before a certain radio play had hit the US from the UK, the people at DEC were like: "What's a 'Slartibartfast'???" Instantly, the reply shot back (and perhaps some of you saw this coming): "Boy, you guys are so unhip it's a wonder your pants down fall down!" :-) :-) Noel

8 years, 4 months

Re: [TUHS] shared memory on Unix

by jnc＠mercury.lcs.mit.edu

> From: "Steve Johnson" > The meetings went on for over a year, but _I NEVER MET WITH THE SAME > PERSON TWICE!_ It seemed that the only thing the marketing group knew > how to do was reorganize the marketing group... Shades of SI:Electric-Marketing (I _think_ that was its name) on the Symbolics LISP Machine... (For those who never had the joy of seeing this, it randomly drew a bunch of boxes with people in them on the screen in a hierarchy, connected them, and then started randomly moving the boxes around... I wonder if the source still exists - or, better yet, a video of it running? Probably not, alas.) Noel

8 years, 4 months

v6 lecture notes

by helbig＠mailbox.org

Hi, my site at the ba-stuttgart was removed. It hosted course ware for my unix v6 lecture. This includes: Unix Programmer's Manual (aka man pages) Documents for use with the Unix Time-Sharing System prepared as postscript files. I provided the man pages as HTML-pages with the references replaced by links. The lecture notes contain tips for installing v6 on the simh emulator, a description of the pdp11 instruction set and hardware as well as a description of unix v6, including booting, kernel and user land software. So if anyone is interested let me know. Greetings Wolfgang Helbig Stauferstr. 22 71334 Waiblingen Germany

8 years, 4 months

Re: [TUHS] PDP-10 in the news today

by jnc＠mercury.lcs.mit.edu

> From: Nigel Williams > Is it a reasonable claim that the PDP-10 made time-sharing "common" > ... I'm presuming that "common" should be read as ubiquitous and > accessible > I'm wondering if it was really the combination of the PDP-11 Good question; I think a case can be made both ways. > (lower-cost more models) One observation I will make: the two don't have identical time-lines; the earliest PDP-10 models predate the PDP-11 by a good chunk, and the PDP-11 out-lasted the PDP-10. So that has a big influence, I think, on the question above. The first PDP-10 (the KA - we'll leave aside the even earlier PDP-6) was made out of small cards with individual transistors (B-series Flip Chips), whereas the earliest PDP-11 model (the -11/20) used SSI TTL on much larger cards. Ditto on the other end: the last PDP-10 sold used 29xx bit-slice technology, whereas the PDP-11 lasted through three generations of microprocessor (the LSI-11, Fonz, and Jaws). Noel

8 years, 4 months

Re: [TUHS] PDP-10 in the news today

by Nelson H. F. Beebe

Nigel Williams <nw(a)retrocomputingtasmania.com> asks on the TUHS list today: >> ... >> Is it a reasonable claim that the PDP-10 made time-sharing "common" >> (note it says "the machine")? I'm presuming that "common" should be >> read as ubiquitous and accessible (as in lower-cost than >> competing/alternative options from other manufacturers or even DEC). >> >> I'm wondering if it was really the combination of the PDP-11 >> (lower-cost more models) and Unix ("free" license to universities) >> that propelled time-sharing, at least at universities. >> ... I worked on the IBM ATS (Administrative Terminal System) for text processing in the early 1970s, and for several years, on the CDC 6400 under both SCOPE and KRONOS operating systems. Those were mainframe environments, but users scattered around campus accessed them via glass terminals, so that was certainly time sharing. Later, for 12 years (1978--1990), I also worked on TOPS-20 on the PDP-10, and that too was time sharing, with most users having a terminal on their desks. We also had PDP-11 and LSI-11 systems, but they ran DEC proprietary operating systems, and were generally dedicated to particular research hardware. It was only in the early 1980s that my institution also began to run Unix systems, initially Wollongong BSD on VAX 750s, and then in 1987, with our first Sun workstations running SunOS. Thus, for me at least, Unix time sharing came a dozen years late (though it was still welcome, and remains so today). ------------------------------------------------------------------------------- - 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, 4 months

PDP-10 in the news today

by Nelson H. F. Beebe

This story appears today in The Register: PDP-10 enthusiasts resurrect ancient MIT operating system Incompatible Timesharing System now compatible with modern machines https://www.theregister.co.uk/2017/01/30/pdp10_enthusiasts_resurrect_ancien… Near the end of the story is a mention of SIMH and of KLH10, both of which emulate the PDP-10. There is also mention of a PDP-11 emulator running inside ITS. ------------------------------------------------------------------------------- - 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, 4 months

Re: [TUHS] PDP-10 in the news today

by jnc＠mercury.lcs.mit.edu

> From: Lars Brinkhoff > several debuggers called RUG and CARPET SYSENG;CARPET > and SYSENG;KLRUG > (and also SYSEN2;URUG >). CARPET runs in the PDP-10, and talks to the 11's via the Rubin 10-11 interface on MIT-AI (which let the PDP-10 see into the PDP-11s' memory); it installed a small toehold in the 11 (e.g. for trap handling). There was also a version (conditionalized in the source) called "Hali" ("Hali is Carpet over a [serial] line") - 'hali' is Turkish for 'carpet' (I wonder how someone knew that). RUG runs in the front-end 11 on the KL (MIT-MC). URUG is a really simple version of RUG that runs in a GT40, and use the GT40 display for output. There's also 11DDT (KLDCP;11DDT >) - not sure why both this and KLRUG exist - unless RUG was for the front-end 11, and 11DDT was for the I/O-11? Noel

8 years, 4 months

Re: [TUHS] PDP-10 in the news today

by jnc＠mercury.lcs.mit.edu

> There is also mention of a PDP-11 emulator running inside ITS. SYSENG;11SIM > Noel

8 years, 4 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal >> the headers say they date from 1974-75. > Wow, that's great! That means that you have the initial version. The file write dates are May 1979, so that's the latest it can be. There is one folder called 'DTI' which contains an email message from someone at DTI to someone at SRI which is dated "10 Apr 1979" so that seems to indicate that that's indeed when they are from. (The message says that the folder contains the source for DTI's IMP-11A driver, which is different from UIll's, although they both descend from the same original version.) > Possibly it is V5 not V6 Nope, definitely V6 here. > All my leads for the 1975 version of this code base came up dry and I > feared it lost. I could have sworn that I'd seen _listings_ of the code in a UIllinois document about NCP Unix that I had found (and downloaded) on the Internet, but I can't find them here now. I did look again and found: "A Network Unix System for the Arpanet", by Karl C. Kelley, Richard Balocca, and Jody Kravitz but it doesn't contain any sources. > it may contain the first version of 'mbufs' It might - the code is conditionalized for "UCBUFMOD" all over the place. > Yes, a 'history' file seems to have been common practice at BBN. The > kernel would have had many modifications: > - the 'ports' extension from Rand Yes. > - the 'await' extension by Jack Haverty Yup. > - an 1822-driver Yes (also by Haverty) - although IMP11-A drivers are all over the place, there are two different ones in the NCP Unix alone. > - possibly, an Autodin II network driver Didn't see one. > - possibly, shared memory extensions Yes, there are two module in 'ken', map_page.c and set_lcba.c (I was unable to work out what 'LCBA' stood for) which seem to do something with mapping. > It might even have some NCP code in it Yes, there's an 'ncpkernel' directory. > There seem to have been two versions of the BBN modified kernel. One was > done for systems without separate I/D with stuff heavily trimmed Yes, there's a 'SMALL' preprocessor flag which conditionally removes some stuff. > The other may have extended the V6 kernel to run in separate I and D > spaces That capability was present in stock V6. Noel

8 years, 4 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > Steve Ward's guys writing Trix hacked together a compiler, assembler and > the like. All of which I have the source for - just looked through it. > If memory serves me, tjt wrote the assembler I have the NROFF source for the "A68 Assembler Reference", and it's by James L. Gula and Thomas J. Teixeira. It says that "A68 is an edit of the MICAL assembler also written by Mike [Patrick].". > Jack Test did much of the compiler and again IIRC that was based on PCC. I dunno, I'm not familiar with PCC, so I can't say. It definitely looks very different from the Ritchie C compiler. Noel

8 years, 4 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal <pnr(a)planet.nl> >> I have this distinct memory of Dave Clark mentioning the Liza Martin >> TCP/IP for Unix in one of the meeting report publihed as IENs > It may be mentioned in this report: > http://web.mit.edu/Saltzer/www/publications/rfc/csr-rfc-228.pdf Yeah, I had run across that in my search for any remnants of the Martin stuff. > Would you know if any of its source code survived? As I had mentioned, I had found some old dump tapes, and had one of them read; it had some bad spots, but we've just (this morning) succeeding in having a look as to what's there, and I _think_ all of the source is OK (including the kernel code, as well as applications like server Telnet and FTP). No SCCS or anything like that, so it's a bit hit or miss doing history - the file write dates were preserved, but of course a lot of them would have been edited over time to fix bugs, add features, etc. The tape appears to contains a _lot_ of other historic material, and it's going to take a while to sort it all out; it includes a Version 6 with NCP from NOSC/SRI, some Unix from BBN; a BCPL compiler; a 'bind' for .rel format files (produced by MACRO-11 and probably BCPL) written in BCPL; programs to convert from .rel to a.out and back; an early verion of Montgomery EMACS; another Unix from 'TMI' (whoever that might be); another UNIX that's somehow associated with TRIX; someone's early kernel overlay stuff; an early 68K C compiler, and also an early 8080 C compiler - just a ton of stuff (that's just a few items that grabbed my eye as I scrolled by). Algol, alas, appears not to be there (we probably didn't add it, because of space reasons). The copy of LISP on this tape seem to be damaged; I do have 3 other tapes, and between them, I hope we'll be able to retrieve it. Noel

8 years, 4 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by jnc＠mercury.lcs.mit.edu

> From: Nick Downing > This is a wonderful find Yes, I was _very_ happy to find those tapes in my basement; up till that, I was almost sure all those bits were gone forever. Thanks to Chuck Guzis, whose old data recovery service made this possible - he actually read the tape. > is it possible for you to read the other tapes also? Alas, they're all of the same system. So the most we're going to get is the files that are missing on this one due to bad spots on the tape. Noel

8 years, 4 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by jnc＠mercury.lcs.mit.edu

> some Unix from BBN This one is from 1979, it includes Mike Wingfield's TCP. The 'Trix UNIX' is a port to the 68K, probably started with something V7ish (I see "setjmp.h" in there). Bits of the Montgomery EMACS appear to date from 1981, but the main source files seem to be from 1984. I also have the source to 'vsh' (Visual Shell), whatever that is. Noel

8 years, 4 months

Early TCP/IP: 3Com UNet

by Paul Ruizendaal

Just stumbled over another early TCP/IP for Unix: http://bitsavers.informatik.uni-stuttgart.de/pdf/3Com/3Com_UNET_Nov80.pdf It would seem to be a design similar to that of Holmgren's (NCP-based) Network Unix (basic packet processing in the kernel, connection management in a user space daemon). In time and in concept it would sit in between the Wingfield ('79, all user space) and the Gurwitz ('81, all kernel) implementations. I think it was distributed initially as a mod versus V7 and later as a mod versus 2BSD. Would anybody here know of surviving source of this implementation? Thanks, Paul

8 years, 4 months

Package Management

by Henry Bent

The recent discussion of Solaris made me think - what was the first Unix to have centralized package management as part of the OS? I know that IRIX had it, I think from the beginning (possibly even for the GL2 releases) but I imagine there was probably something before that. -Henry

8 years, 4 months

Oracle euthanizes Solaris 12, expunging it from roadmap

by Kay Parker

guess it is the beginning of the end of Solaris and the Sparc CPU: 'Rumors have been circulating since late last year that Oracle was planning to kill development of the Solaris operating system, with major layoffs coming to the operating system's development team. Others speculated that future versions of the Unix platform Oracle acquired with Sun Microsystems would be designed for the cloud and built for the Intel platform only and that the SPARC processor line would meet its demise. The good news, based on a recently released Oracle roadmap for the SPARC platform, is that both Solaris and SPARC appear to have a future. The bad news is that the next major version of Solaris—Solaris 12— has apparently been canceled, as it has disappeared from the roadmap. Instead, it's been replaced with "Solaris 11.next"—and that version is apparently the only update planned for the operating system through 2021. With its on-premises software and hardware sales in decline, Oracle has been undergoing a major reorganization over the past two years as it attempts to pivot toward the cloud. Those changes led to a major speed bump in the development cycle for Java Enterprise Edition, a slowdown significant enough that it spurred something of a Java community revolt. Oracle later announced a new roadmap for Java EE that recalibrated expectations, focusing on cloud services features for the next version of the software platform. ' http://arstechnica.com/information-technology/2017/01/oracle-sort-of-confir… -- Kay Parker kayparker(a)mailite.com -- http://www.fastmail.com - The way an email service should be

8 years, 4 months

Was pcc ever ported to the CDC6600?

by Nemo

All this talk of targets for UNIX makes me wonder (given the eccentricity of the machine). N.

8 years, 4 months

Working Group for Release of 8th, 9th, 10th Ed Unix?

by Warren Toomey

Now that we have quite a few ex-Bell Labs staff on the list, and several other luminaries, and with the Unix 50th anniversary not far off, perhaps it is time to form a working group to help lobby to get 8th, 9th and 10th Editions released. I'm after volunteers to help. People who can actually move this forward. Let me know if and how you can help out. Thanks, Warren

8 years, 4 months

Oracle euthanizes Solaris 12, expunging it from roadmap

by Rudi Blom

I'm a bit puzzled, but then I only ever worked with some version of Ultrix and an AT&T flavour of UNIX in Philips, SCO 3.2V4.2 (OpenServer 3ish), DEC Digital UNIX, Tru64, HP-UX 1123/11.31 and only ever used "mkdir -p". Some differences in the various versions are easily solved in scripts, like shown below. Not the best of examples, but easy. Getting it to work on a linux flavour wouldn't be too difficult :-) OS_TYPE=`uname -n` case "${OS_TYPE}" in "OSF1") PATH=".:/etc:/bin:/sbin:/usr/bin:/usr/sbin:/xyz/shell:/xyz/appl/unix/bin:/xyz/utils:" TZ="THA-7" ;; "HP-UX") PATH=".:/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/contrib/bin:/xyz/field/scripts:/xyz/shell:/xyz/appl/unix/bin:/xyz/utils:" TZ="TST-7" ;; *) echo "${OS_TYPE} unknown, exit" exit 1 ;; esac

8 years, 4 months

Re: [TUHS] [TUHS} PDP-11, Unix, octal?

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy > Perhaps the real question is why did IBM break so completely to hex for > the 360? Probably because the 360 had 8-bit bytes? Unless there's something like the PDP-11 instruction format which makes octal optimal, octal is a pain working with 8-bit bytes; anytime you're looking at the higher bytes in a word, unless you are working through software which will 'interpret' the bytes for you, it's a PITA. The 360 instruction coding doesn't really benefit from octal (well, instructions are in 4 classes, based on the high two bits of the first byte, but past that, hex works better); opcodes are 8 or 16 bits, and register numbers are 4 bits. As to why the 360 had 8-bit bytes, according to "IBM's 360 and Early 370 Systems" (Pugh, Johnson, and Palmer, pp. 148-149), there was a big fight over whether to use 6 or 8, and they finally went with 8 because i) statistics showed that more customer data was numbers, rather than text, and storing decimal numbers in 6-bit bytes was inefficient (BCD does two digits per 8-bit byte), and ii) they were looking forward to handling text with upper- and lower-case. Noel

8 years, 4 months

Re: [TUHS] [TUHS} PDP-11, Unix, octal?

by Doug McIlroy

> I understand why other DEC architectures (e.g. PDP-7) were octal: 18b is a multiple of 3. But PDP-11 is 16b, multiple of 4. Octal predates the 6-bit byte. Dumps on Whirwind II, a 16-bit machine, were issued in octal. And to help with arithmetic, the computer lab had an octal Friden (IIRC) desk calculator. One important feature of octal is you don't have to learn new numerals and their addition and multiplication tables, 2.5x the size of decimal tables. Established early, octal was reinforced by a decade of 6-bit bytes. Perhaps the real question is why did IBM break so completely to hex for the 360? (Absent actual knowledge, I'd hazard a guess that it was eased in on the 7030.) Doug> I understand why other DEC architectures (e.g. PDP-7) were octal: 18b is a multiple of 3. But PDP-11 is 16b, multiple of 4. Octal predates the 6-bit byte. Dumps on Whirwind II, a 16-bit machine, were issued in octal. And to help with arithmetic, the computer lab had an octal Friden (IIRC) desk calculator. One important feature of octal is you don't have to learn new numerals and their addition and multiplication tables, 2.5x the size of decimal tables. Established early, octal was reinforced by a decade of 6-bit bytes. Perhaps the real question is why did IBM break so completely to hex for the 360? (Absent actual knowledge, I'd hazard a guess that it was eased in on the 7030.) Doug =

8 years, 4 months

Re: [TUHS] TUHS Digest, Vol 14, Issue 63

by jnc＠mercury.lcs.mit.edu

> From: Joerg Schilling > Was T1 a "digital" line interface, or was this rather a 24x3.1 kHz > channel? Google is your friend: https://en.wikipedia.org/wiki/T-carrier https://en.wikipedia.org/wiki/Digital_Signal_1 > How was the 64 ??? Kbit/s interface to the first IMPs implemented? > Wasn't it AT&T that provided the lines for the first IMPs? Yes and no. Some details are given in "The interface message processor for the ARPA computer network" (Heart, Kahn, Ornstein, Crowther and Walden), but not much. More detail of the business arrangement is contained in "A History of the ARPANET: The First Decade" (BBN Report No. 4799). Details of the interface, and the IMP side, are given in the BBN proposal, "Interface Message Processor for the ARPA Computer Network" (BBN Proposal No. IMP P69-IST-5): in each direction there is a digital data line, and a clock line. It's synchronous (i.e. a constant stream of SYN characters is sent across the interface when no 'frame' is being sent). The 50KB modems were, IIRC, provided by the Bell system; the diagram in the paper above seems to indicate that they were not considered part of the IMP system. The modems at MIT were contained in a large rack, the same size as the IMP, which stood next to it. I wasn't able to find anything about anything past the IMP/modem interface. Perhaps some AT+T publications of that period might detail how the modem, etc, worked. Noel

8 years, 4 months

Re: [TUHS] [TUHS} PDP-11, Unix, octal?

by Nelson H. F. Beebe

On the subject of the PDP-10, I recall seeing people at a DECUS meeting in the early 1980s wearing T-shirts that proclaimed I don't care what they say, 36 bits are here to say! I also recall a funny advertizing video spoof at that meeting that ended with the line At DIGITAL, we're building yesterday's tomorrow, today. That meeting was about the time of the cancellation of the Jupiter project at DEC that was planned to produce a substantially more powerful follow-on to the KL-10 processor model of the PDP-10 (we had two such at the UofUtah), disappointing most of its PDP-10 customers. Some of the Jupiter technology was transferred to later VAX models, but DEC never produced anything faster than the KL-10 in the 36-bit line. However, with microcomputers entering the market, and early workstations from Apollo, LMI, Sun, and others, the economics of computing changed dramatically, and departmental mainframes ceased to be cost effective. Besides our mainframe DEC-20/60 TOPS-20 system in the College of Science, we also ran Wollongong BSD Unix on a VAX 750, and DEC VMS on VAX 780 and 8600 models. In 1987, we bought our first dozen Sun workstations (and for far less than the cost of a DEC-20/60). After 12 good years of service (and a forklift upgrade from a 20/40 to a 20/60), our KL-10 was retired on 31-Oct-1990, and the VAX 8600 in July 1991. Our productivity increased significantly in the Unix world. I wrote about memories and history and impact of the PDP-10 in two keynote addresses at TUG meetings in articles and slides available at http://www.math.utah.edu/~beebe/talks/2003/tug2003/ http://www.math.utah.edu/~beebe/talks/2005/pt2005/ ------------------------------------------------------------------------------- - 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, 4 months

Re: [TUHS] Article on 'not meant to understand this'

by Steve Johnson

I was well aware of the comment in V6, but had no idea what it referred to. When Dennis and I were porting what became V7 to the Interdata 8/32, we spent about 10 frustrating days dealing with savu and retu. Dennis did his most productive work between 10pm and 4am, while I kept more normal hours. We would pore over the crash dumps (in hex, then a new thing for us--PDP-ll was all octal, all the time). I'd tinker with the compiler, he'd tinker with the code and we would get it to limp, flap its wings, and then crash. The problem was that the Interdata had many more registers than the PDP-11, so the compiler only saved the register variables across a call, where the PDP-11 saved all the registers. This was just fine inside a process, but between processes it was deadly. After we had tried everything we could think of, Dennis concluded that the fundamental architecture was broken. In a couple of days, he came up with the scheme that ended up in V7. It was only several years later when I saw a T-shirt with savu and retu on it along with the famous comment that I realized what it had referred to, and enjoyed the irony that we hadn't understood it either... Steve ----- Original Message ----- From: "Brantley Coile" <brantleycoile(a)me.com> To:"Larry McVoy" <lm(a)mcvoy.com> Cc:<tuhs(a)tuhs.org> Sent:Mon, 16 Jan 2017 05:11:02 -0500 Subject:Re: [TUHS] Article on 'not meant to understand this'

8 years, 4 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