Ah, thank you Paul, for sharing this story. Postings like this make cctalk worth every penny, IMO!
Regards,
Freek.
-----Original Message-----
Date: Tue, 08 Jul 2025 21:30:36 -0000
From: paul.kimpel(a)digm.com
Subject: [cctalk] Burroughs backplane story, was Re: Another 780
backplane story
To: cctalk(a)classiccmp.org
Message-ID: <175201023609.1228.2550589532797629102(a)classiccmp.org>
Content-Type: text/plain; charset="utf-8"
In early 1971, I started working as an on-site software tech on a rather large (for the time), dual-processor Burroughs B6500. It was early days for that system, and we had a lot of problems with it in the field. We got those ironed out pretty well and eventually got the system up to an acceptable level of operation.
<<< snip>>>
We finally deduced that the problem had been present since the system left the factory floor. The original I/O software had been so poor that the system was seldom (if ever) able to initiate more than one I/O to disk at a time, but the new version we had recently installed was really good at initiating multiple I/Os. Mux 1 had a lower selection priority than Mux 0, so under the old software it was seldom selected, and perhaps never so for tag transfer I/Os, which are relatively rare. The new software allowed the system to get busy enough that Mux 1 started to be used a lot more often, and eventually it got busy enough that a paging I/O for that master PCW array got scheduled to Mux 1, and the system just didn't survive for very long after that.
In early 1971, I started working as an on-site software tech on a rather large (for the time), dual-processor Burroughs B6500. It was early days for that system, and we had a lot of problems with it in the field. We got those ironed out pretty well and eventually got the system up to an acceptable level of operation.
About a year later, a major upgrade to the MCP (the OS) was released. A major component of that release was a completely rewritten I/O subsystem with much higher reliability and much, much better performance, especially in "Logical I/O," the interface between user programs and the memory buffers and physical I/O mechanism. Soon after installing this release, we started to get fatal system crashes in Logical I/O.
Describing what was happening requires a little background on the system architecture. The B6500, like its predecessor the B5500, is known as an ALGOL-oriented stack machine, but it is less well-known as a type of capability system. To support that, it used a segmented memory model and tagged memory. Each word had an extra three bits, not accessible to user programs, that identified the type of data in a word. For example, tag 0 was ordinary data, tag 2 indicated a double-precision word, tag 5 was a data descriptor through which data segments were addressed, and tag 7 was a Program Control Word (PCW) that effectively addressed a location in an object-code segment. It was used primarily as a procedure (subroutine) entry-point address.
In reading the dumps from the crashes and the MCP source code, we started to learn how the new Logical I/O mechanism worked. It cleverly used the stack addressing of the system to implement a very object-oriented interface. The "methods" of this interface were small procedures that were customized to handle very specific cases of record handling -- random vs. sequential I/O, blocked vs. unblocked I/O, translation or no translation, etc.
There were scores of these methods. The idea was do a little as possible for each user request and to avoid making as many decisions as possible and to optimize the buffer handling in each case. There were about a half-dozen different types of user requests, and the methods for those were accessed through a branch table in the FIB (control block) for each open file. That branch table contained PCWs for the appropriate methods needed by that file. The table was set up during file open, but could be changed as the nature of the user program's requests changed, e.g., from sequential to random access.
We discovered that the crash was caused by some PCWs in the file-level branch tables having tags of 5 instead of tags of 7. Attempting to call a procedure using a tag-5 word was a no-no that was trapped by the hardware, hence the fatal dump. Then we discovered that the branch tables were loaded from a master array of PCWs for all of the possible methods, and when we looked at that array in the dump, ALL of the PCWs in the array had tags of 5! We know that array initially had to have had words with tags of 7, because the system had run for quite a while before crashing, so how could all of the words in the array suddenly have changed to tags of 5? There wasn't any straightforward way to do that in software.
That master array was loaded from from the OS image on disk at the initial boot, but then we found out the array was overlayable -- it could be paged out and back in by the virtual memory mechanism. So we began to suspect there was an issue with I/O. Normally, a disk read stored words in memory with a constant tag of 0, but there was a special I/O mode, termed "tag transfer," that would read and write the tag bits along with the regular data bits.
Fortunately, the other tech on the site had worked in the MCP group for a while and knew the I/O hardware pretty well, so he started writing some standalone programs to exercise the hardware in specific ways. This system had two I/O Multiplexors (multi-channel DMA units) numbered 0 and 1, and the disk drives were dual-ported so that either Mux could address any of them. My colleague's programs tried doing I/Os with various combinations of Mux and channel assignments. And as you might expect by now, he discovered that doing a tag transfer read through Mux 1 always dropped the middle tag bit.
We turned that finding over to the on-site Field Engineers, who pulled out their schematics and started tracing signals. It took several hours, but eventually they discovered not a loose wire, but that Mux 1 was completely missing a wire. Of course, it was the wire that carried the middle bit of the tag during tag transfer.
We finally deduced that the problem had been present since the system left the factory floor. The original I/O software had been so poor that the system was seldom (if ever) able to initiate more than one I/O to disk at a time, but the new version we had recently installed was really good at initiating multiple I/Os. Mux 1 had a lower selection priority than Mux 0, so under the old software it was seldom selected, and perhaps never so for tag transfer I/Os, which are relatively rare. The new software allowed the system to get busy enough that Mux 1 started to be used a lot more often, and eventually it got busy enough that a paging I/O for that master PCW array got scheduled to Mux 1, and the system just didn't survive for very long after that.
For those of you who wanted the Qbus backplanes here is the list.
I've been moving things around and found them while looking for something
else.
Please contact me off list with any questions.
H9270 4 x 4 used in the BA11-M for the original PDP11/03
H9270 with card cage
complete 11/03 box, boards available
H9276-B
H9276-B with card cage
H9278-A
2x12 micro backplane with card cage
BA123-A
Sygma 4x8 with card cage
Heath
While not on a 780 back plane, about 50 years ago, I was basically in
charge of some 26 PDP16M computers. Periodically, one of the chips would
be found with the top blown off. At some point, I pulled the computer
and examined the backplane filled with wirewrap wires.
The solution turned out to be fairly simple... a -15V bus was about
.001" near one of the wirewrap posts. A slight moving of that bus away
from the wirewrap post solved that problem. I have to assume it was a
temperature related problem since increasing that spacing solved the
problem.
Unrelated to the computer problem, another source of angst was
intermittently one of those computers would crash. That one took
probably a year to find... one of the interface M series pullup cards
had a pulldown card installed in its place.
I should mention all the above took place on a newly install system.
Marvin
I worked part time at a computer center for a large bank while getting my undergraduate degree.
The center was getting one of the first IBM 3081 machines to replace the existing 3033 MP.
Because of the helium filled modules, getting the machine from the climate controlled truck to the center, which was on the 7th floor of the bank building was crazy; the move had to be accomplished in 30 minutes. As a dry run, IBM supplied a size and weight dummy 3081 in advance to make sure the delivery went smoothly.
As you might imagine, the install and switch over to the 3081 was high profile. The VP in charge of the center was under pressure to get it done on schedule.
The delivery and initial install went according to plan. The data was migrated to the new disks and the various application software was run through its paces.
Unfortunately, the 3081 would occasionally throw a power fault. The local FE’s could not determine the cause, so after a week or so second level support was called in. They could not figure it out, so IBM brought in Ivan (I think that was his name). You know when you get the hot shot from IBM when he arrives in bib overalls and tennis shoes, not a suit and 5 pound wingtips.
After the second day, Ivan got tired of the stream of managers asking him when the 3081 would be available, so he went down the the main bank floor and grabbed the thing (I cannot remember the proper name) banks used to use to create teller lines (posts and satin “ropes”), and formed a cordoned area around the 3081’s console. Note that each computer console had a telephone (1 for each 3033 and one for the new 3081) for communicating with the computer operator.
On the third day, the VP bypassed the cordon and asked Ivan when the 3081 would be operational and Ivan replied he was’t sure. The VP said he had already told the president it would be up by the end of the day, and Ivan handed the VP the phone on the console and said, and I quote, “Call someone who cares”. I kid you not, I still remember verbatim.
Early afternoon of the third day, Ivan asked the Lead FE to get a torch. There was an awesome hardware store about 6 blocks away, so in about 20 minutes the torch was delivered.
The power bus on the 3081 had enormous cables composed stranded 4-6 large gauge wires that were soldered to large metal plates. Ivan had determined that the wires were improperly soldered and used the torch to resolder them.
You can imagine the horror on the faces of the staff as Ivan opened the power bay, lit the torch, and started melting the solder.
And it worked! No more power faults.
— Todd
As requested, here is a partial list of the 8-A parts available. I have a
few more to go through, but most are on here except for possibly a 128K
memory board.
I have some omnibus boards, M8357 RX8e, LA180, LQP, etc, and will try to
make a list next week. If you need something not on here, please ask.
I have at least one of each of the following, and more than one of some.
G8016
G8018
H9194 12 slot 8-A backplane
limited front panel
programmers panel
MM8-AA
MM8-AB
M8315
M8316
M8317
M8319
M8416
M8417
Also some non dec:
REMEX PC8E
core memory
A complete 8-A mounted in the desk with RX02s. It's currently in the back
of a 20 or 25 foot rental locker, but I hope to get it out this summer. It
came with a LA35 and maybe a VT52.
Dear list members,
I was wondering if anybody is aware of VAX 86x0 schematics having survived the product life cycle within DEC? I searched the web extensively but could not find any hints on this.
It seems that DEC never published such details as schematics for the successor of the VAX 11/78x systems, not even on microfiche, maybe due to the macrocell array implementation (just a guess). All I could find is that there were illustrated parts list on microfiche.
However, maybe Hewlett Packard handed DEC-internal documents over to a museum such as the CHM? Or a former designer still have schematics in their archives?
Any pointers would be greatly appreciated!
Best regards,
Pierre
-----------------------------------------------------------------------------
http://www.digitalheritage.de
Jon Elson's take hits home. A 780 was delivered and VMS was running. We
installed 4.1BSD and it ran fine until it crashed. Field service insisted
we needed a full set of RS-232 wires in our cable. Still crashed
(surprise!). Switched to VMS, still crashed after a while. Local field
service couldn't find it. The big guns flew in from Maynard. First day:
Couldn't find it. Second day: "What, what's that wire doing there? Have a
wire-wrap tool?". Removed wire from backplane. Boots, runs. Engineer
flies home.
