To answer Jon's following question (2 minutes later): ------------------------------------------------------------------------ Oh yeah, and I think that this is why Heinz wrote MERT, but he should know more than me about it. ------------------------------------------------------------------------ Yes, my Dept. in MH was involved in the early days of digital switching and the need for real-time response was certainly recognized. But MERT was not developed with a specific telephony project in mind. I was mostly involved in software in support of current projects being done in the Dept. We started the MERT project at the time that DEC announced their PDP-11/45 mini-computer in the early 1970's because it supported 3 separate address spaces - system, supervisor, and user. This enabled us to run operating system environments with different user application program needs, specifically real-time under control of one supervisor and time-sharing applications in another supervisor, to start with. Hence its name - Multi-Environment Real Time (MERT). Once we had MERT up and running on the PDP-11/45 and PDP-11/70 computers, some projects in other Bell Labs locations involved in telephony projects started building their projects on the MERT system. The DMERT system was developed later on by projects at yet another Bell Labs location. Heinz On 9/25/2023 6:37 PM, Jon Steinhart wrote:

On Tue, Oct 3, 2023 at 11:52 PM Kevin Bowling <kevin.bowling(a)kev009.com> wrote: I was reviewing this book https://archive.org/details/computerhardware0000toyw and it is one of the best computer architecture books I've seen. Somehow in 400 pages the authors manage to cover logic, language implementation, compilation, instruction set design, various aspects of operating systems design, and fault tolerance citing timeless pedagogical hardware (PDP11, VAX, S/370, System/38, iAPX-432, WE32000) and software (VMS, UNIX, DMERT). Readers of this list will enjoy it!

Andrew Hume <andrew(a)humeweb.com> writes: So... I am speaking from a single point of view about stuff I worked on a very long time ago.... On the operations support system I worked on at AT&T/Lucent... we supported all manor of switches, all of those made by AT&T/Lucent and a whole lot made by other companies. This is what I recall... I believe that the 1A had left the building and no longer existed in any installed base in the US when I started, although we supported it still in our software because of the pain of ripping it out. The 1E did exist in some numbers (I may have these backwards, BTW... it might have been the 1A that existed and the 1E had crossed the rainbow bridge). I do recall that either the 1A or 1E had a lot of features, but it may have been more of a case of it just being around a long time and was infected with warts. The work horses, however, were the 4ESS and the 5ESS. The 4E did the long haul work and was often configured in a tandem set up (that was the term used, Tandem, which meant something specific at the time). The 4E was also a very large monster of a device... taking up pretty much an entire floor of a building. The software in it was very old with lots of add on sub-devices to provide new ability (our product used some of those sub-devices). Those sub-devices might have run their own operating systems and could have been computers all by themselves... that is, there were multiple glued together computers to get the 4E effect. The 5E was a lot cleaner and much smaller. It also had some sub-device stuff going on but nothing like what the 4E had. I do seem to recall that the 5E runs some version of Unix, at least on part of the device, but I don't remember if the main switching engine did, however (I suspect not, BTW). I am almost 100% sure that the 4E did not run Unix on the main switching engine, but it would not surprise me that it found its way into it somewhere or other (probably in multiple places given how large the device was). The 5E and 4E may have started out life with particular roles, but this wasn't very strict. That is it was completely ok for a 5E to do long haul work if so configured and it was very possible for a 4E to terminate a call. There was a great deal of flexibility present. AT&T long wire was a bit of a different place with respect to the 4E.. I seem to remember that at the time I was there they had something like 800 4E configured to do long distance service in the US. At least the traffic management part was managed by a set of Amdauls (using Unix as the operating system I believe) running an operation system product that was very much related to the one I worked on... simular internals for example and in my early days we all sat in the same group. The product I worked on also supported the SS7 switches (I say "switches" here, but that probably isn't exactly what they were. I also don't remember their actual names... STM, maybe??). I worked with the SS7 development group on a new operations system interface and during that conversation they mentioned that the SS7 switch ran a more or less unmodified Unix Solaris (one would assume on a Sparc). They also mentioned that they had performed kernel modifications in the past, but the cost of maintaining that sort of thing was very high, so they had moved away from doing that towards a more "push it to userland" way of thinking. -- Brad Spencer - brad(a)anduin.eldar.org - KC8VKS - http://anduin.eldar.org

Hello, You beat me to it! I was about to reply that the Connections Museum of Seattle would have more info about this, or know people who do. This video of their channel shows a 3ESS software boot : https://www.youtube.com/watch?v=k865-VjWUk8 Sebastien Le 26/09/2023 à 04:20, Kevin Bowling a écrit :

It may be obvious, certainly to anyone who owns the BSTL series (I don't. I read it in the library at uni), but would I be right in thinking the motivation behind "real time UNIX" was switching? It's the closest problem to Bell labs which demands time critical outcomes, the delay tolerance in circuit establishment and end-to-end telephony signaling was there, but it was finite. And, for capacity planning purposes being told a single unit of UNIX logic controlling a telephone switch could handle X call setup and tear-down events per second meant you could do the Erlang sums over customers call volumes and phone handset counts. The british digital switch experience in the System-X series Was GEC/Plessey, and ran CORAL which was the real time system they used to do MILSPEC stuff. It was explicitly fault tolerant design, lots of 2 and triple redundant componentry. -G