TUHS

tuhs@tuhs.org

17 participants
6470 discussions

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

by Dave Horsfall

[ Warning: you need to be an OF to understand the references ] Time to re-post this... And trust me, an IBM 3090 was really big iron in those days. I don't recall the author, but I found it on the 'net. ----- 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 RA60s running a single application, PC style, into a data center with two IBM 3090s 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

4 years, 6 months

Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by norman＠oclsc.org

Just for completeness: I have one OpenBSD 6.7 system at home and look after several more at work, and yes, OpenBSD still has raw disk devices. Norman Wilson Toronto ON

4 years, 6 months

Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by jnc＠mercury.lcs.mit.edu

> I noticed a place where I used R0 as a temp ... and was being bashed. > So I fixed it, and now the shell starts OK, but attempting to do any > command (e.g. "echo foo"), things hang Well, I had 'fixed' it; it turned out my 'fix' had a bug. :-( (The code I had to change for the /03 there was pushing the old PS, and that and the temp I had to push got intermangled.) Anyway, with that fixed, the /03 Mini-Unix works now. The old user command binaries seem to work OK on the /03; not that I've tried the all, but the ones I have tried (including the C compiler) all worked. They all should all work (there's nothing in user code that's model-dependent). I have tweaked the shell (to allow 'cd') and init (to get rid of the annoying long rights message), but that's all. The latest, greatest mch.s is uploaded: http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/mch.s Although a couple of files (bio.c, clock.c, slp.c, and tty.c) had minor changes (to remove direct rerferences to the PS; they now call getps() and putps() for that), and main.c has minor changes to work when there's no KW11 or switch register, really the only file with significant changes for the /03 is mch.s. It's the only one where the object code is model-dependent; all the other changed ones use the same object code for all CPU models. I'll put up a Web page with details, links to sources, etc, 'soon'. A couple of other things. Mini-Unix has removed 'raw' devices (not sure why, probably seemed un-needed), so other disk drivers (e.g. the RL11 driver) aren't straight drop-ins. Minimal tweaks needed, though; just remove the read and write routines, I think. If there was a real use for 'raw' devices, they could probably be added back, but physio() would have to be modified (simplified). Not sure if anything else special would be needed; the process can't be swapped while raw I/O is ongoing, and so on Mini-Unix no other process could run. Probably OK, but needs to be checked. I recommend that everyone trying to run Mini-Unix on a hardware /03 invest in a KEF11 chip. (There are a few on eBait.) That way, you can leave the EIS emulator out of the build, which will save some space, and allow more room for device drivers. I added kernel printf() into the build, to help with debugging, but it can be removed to save space. You can change the system to use more room for the kernel (see the Mini-Unix docs), but that involves re-linking _every single user command_, including the shell and init. Not recommended. Noel

4 years, 6 months

Stanley lieber

by Andrew Hume

can stanley lieber contact me please (regarding an 8th edition manual)? i can’t contact you via sl(a)stanleylieber.com (because of an SPF error), so perhaps via another email address. thanks

4 years, 6 months

Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by jnc＠mercury.lcs.mit.edu

> From: Paul Riley > port Mini-Unix will create some demand for device drivers on the /03 > systems, so may be worthwhile to implement RAW device. I'm not sure I understand this ("worthwhile to implement RAW device"); let me explain what the removal of 'raw' I/O devices from MINI-UNIX really means, and then ask what it is that you are after. Early Unix (no idea about later ones) supports two classes of devices; 'block' devices, which can be used to hold file-systems, and 'character' devices, which cannot. (I seem to recall a paper, perhaps from the Unix BSTJ issue, which talks about them in some detail.) The former are those where the underlying physical device has restricted semantics; they are block-addressable mass storage devices. All access to them is via the system's block buffer pool, so reads/writes by the user of arbitrary size and location are possible. 'Character' devices are everything else. 'Raw' devices are an interface to the devices of 'block' devices which does not go through the system's buffer pool; I/O operations to them perform DMA directly to the user process' memory. They are 'character' devices, in the Unix device taxonomy. The only semantics available are those supported by the hardware - e.g. seeks only to block boundaries. So when I say that MINI-UNIX doesn't have 'raw' devices, it just means that e.g. the RK disk controller device _only_ talks to the Unix block buffer system; if a user program wants to look at the disk contents, it has to go via that system. So, with that in hand, what exactly is the need you forsee for raw devices in MINI-UNIX? Also, I've started to work on getting the V6 RL driver to work in MINI-UNIX; it should have been easy (just delete the charater device interface), but for some reason it didn't work when I tried it. I'll look at it in more detail 'soon'. Noel

4 years, 6 months

Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by jnc＠mercury.lcs.mit.edu

> From: Jay Logue > Are your other changes available anywhere? Yeah, they're all up-loaded, and linked to from my 'Running MINI-UNIX on the LSI-11' page: http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/Mini.html It's mostly done, but I'll probably continue to tweak it a bir. If anyone notices any errors, or has questions that aren't answered there, etc please let me know. > Also, I was wondering if it might be useful to have a github repo with > these changes. I'd be happy to help set this up. Feel free to go for it, if people think it would be useful. (I'm not sure there is a 'basic' MINI-UNIX repo to start on.) Noel

4 years, 6 months

Origins of globbing

by Tyler Adams

How did globbing come about in unix? Related, as regexes were already well known because of qed/ed, why wasn't a subset of regular expressions used instead? Tyler

4 years, 6 months

Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by jnc＠mercury.lcs.mit.edu

> From: Paul Riley > Always darkest before the dawn. Well, we'll see. I found _that_ one; process 1 managed to exec() init, do a fork(), and then the child process exec()'d the shell - then that apparently died, and the code in init falls through into: termall(); execl(init, minus, 0); when the single-user shell exits, so then init restarted; rinse, repeat. So a _lot_ of the code in mch.s seemed to be working correctly; system calls (2 exec()'s, and a fork()) worked, processing switching worked, device interrupts (for the disk and console tty) seemed to be working.. Not sure what's left! So I looked at mch.s again, to see what else _was_ there, and I noticed a place where I used R0 as a temp - with the MFPS/MTPS thing to get to the PS, instructions like: BIS #340, PS need to change to: MFPS R0 BIS #340, R0 MTPS R0 and R0 was being used to hold an arg (in pword:), and was being bashed. So I fixed it, and now the shell starts OK, but attempting to do any command (e.g. "echo foo"), things hang (the shell doesn't fork). If I type the interrupt character, the shell exits, and init restarts. Oh well, hopefully this one won't be too painful to work out. The system's mostly working, which I think will really help. Noel

4 years, 6 months

Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by jnc＠mercury.lcs.mit.edu

> Now to see if 'cc' works on an '-11/40' Yeah, the C compiler works fine on a /40; so the SOB bug (or perhaps some _other_ one I haven't found yet) must have affected it too. The thing that's odd about that bug is that SOB works _sometimes_ on an /05; the 'rkmx' on the distro tape will boot (which if the SOB _never_ worked, it wouldn't). So there must be a data dependency somehow. John Wilson says the SOB is very optimized, so maybe there's a bug. > then back to the /03. Well, I tried /03 version, and it doesn't work; /etc/init continually restarts. The thing is that _every_ file except mch.s is identical between the '05' version (which runs fine on the /40; above), and the /03 version. So the bug must be in mch.s - unless there's somehow an /03 dependency somewhere else I missed. I looked through init.c, didn't see anything. Here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/mch.s is the mch.s source, if anyone wants to look through it and see if they see anything. It's conditionalized for the /03; there's a very simple header file (here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/03mch.s for the 03 version) to set the flags (so one doesn't have to edit the main file to change the flag settings). I had a careful look at mch.s, before I started, checking all the added conditionalized code; found one that could have been an issue (I was using a temporary register, r0, that had needed data in it), but the rest all looked OK. I have some ideas on how to proceed on working out what's going on, but I'm done for today, gotta do other stuff. Noel

4 years, 6 months

Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by jnc＠mercury.lcs.mit.edu

> I suspect there must be an issue with the -11/05 emulation in Ersatz-11 There is. The C compiler on MiniUnix emits SOB instructions. The -11/05 doesn't implement SOB; however, the instruction emulator in MiniUnix (emul.s) is prepared to emulate it. (So MiniUnix should work fine on real -11/05's.) However, when set to an -11/05, Ersatz-11 treats SOBs as NOPs; they fall through without any effect. Without a trap, they can't be emulated either. This caused the problem with namei() failing (namei() calls bcopy(), which has a SOB in it), and probably caused the problem I was seeing with the C compiler, but I'm too burned out to check right now. Tomorrow. Noel

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